Devices and methods for network integration of an hvac device

ABSTRACT

A communication circuit for providing communication to an actuator. The communication circuit includes a device interface and a network interface. The device interface is configured to provide a serial communication link between the communication circuit and a processing circuit of the actuator. The network interface is in electronic communication with the device interface, and configured to communicate with an external network. The device interface is configured to receive data values from the actuator via the serial communication link. The device interface is further configured to populate one or more attributes of an equipment object stored in the device interface with the received data values. The network interface is further configured to map the attributes of the equipment object with individual networking objects, and write the attributes to the mapped individual networking objects. The network interface further configured to communicate the individual networking objects to the external network.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of and priority to U.S. ProvisionalPatent Application No. 62/331,875 filed May 4, 2016, the entirety ofwhich is herein incorporated by reference. This application furtherclaims the benefit of and priority to U.S. Provisional PatentApplication No. 62/321,729 filed Apr. 12, 2016, the entirety of which isalso herein incorporated by reference.

BACKGROUND

The present disclosure relates generally to building management systemsand associated devices. The present disclosure relates more particularlyto devices, systems and methods for integrating non-networked buildingmanagement devices onto an existing network to allow for integration ofthe building management device into the building management system.

A building management system (BMS) is, in general, a system of devicesconfigured to control, monitor, and manage equipment in or around abuilding or building area. A BMS can include a heating, ventilation, andair conditioning (HVAC) system, a security system, a lighting system, afire alerting system, another system that is capable of managingbuilding functions or devices, or any combination thereof. BMS devicescan be installed in any environment (e.g., an indoor area or an outdoorarea) and the environment can include any number of buildings, spaces,zones, rooms, or areas. A BMS can include a variety of devices (e.g.,HVAC devices, controllers, chillers, fans, sensors, etc.) configured tofacilitate monitoring and controlling the building space. Throughoutthis disclosure, such devices are referred to as BMS devices or buildingequipment.

In some existing systems, third party supplied devices can usestandalone systems that do not have the means for communicating on thelarger BMS network. Either a separate network is provided for thestandalone systems, or a user may have to directly interface with thestandalone system. For example, common BMS devices such as valves andactuators may not contain the necessary hardware to communicate over theBMS network. Further, larger devices and systems, such as boilers and/orchillers, may contain proprietary communication protocols and networksand not interface with a BMS network. Thus, it would be desirable to beable to provide an interface to allow for a standalone system to beintegrated into an existing BMS network.

SUMMARY

One implementation of the present disclosure is a communication circuitfor an actuator. The communication circuit includes a device interfaceand a network interface. The device interface is configured to provide aserial communication link between the communication circuit and aprocessing circuit of the actuator. The network interface is inelectronic communication with the device interface, and configured tocommunicate with an external network. The device interface is configuredto receive data values from the actuator via the serial communicationlink. The device interface is further configured by the processingcircuit to populate one or more attributes of an equipment object storedin the device interface with the received data values. The networkinterface is further configured to map the attributes of the equipmentobject with individual networking objects, and write the attributes tothe mapped individual networking objects. The network interface furtherconfigured to communicate the individual networking objects to theexternal network.

Another implementation of the present disclosure is a communicationcircuit for providing network communications to an actuator. Thecommunication circuit includes a processing circuit. The processingcircuit includes a processor and a memory. The processor is configuredto communicate with the actuator and configured to receive data valuesfrom the actuator. The memory is in communication with the processor andincludes an equipment object. The equipment object includes one or moreattributes associated with the actuator. The processing circuit isconfigured to map the received data values to the one or more attributesof the equipment object. The communication circuit further includes anetwork transceiver, the network transceiver configured to transmit themapped values in the equipment object to a network using a communicationinterface.

A further implementation of the present disclosure is a method ofcommunicating HVAC device attributes to a network. The method includesreceiving one or more data values associated with the HVAC device at acommunication circuit via a communication link. The method furtherincludes writing one or more data values to an equipment object, theequipment object mapping the data values to an associated of theequipment object. The method also includes mapping the attributes of theequipment object to one or more standard networking objects. The methodfurther includes transmitting the standard networking object to anetwork.

Those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the devices and/orprocesses described herein, as defined solely by the claims, will becomeapparent in the detailed description set forth herein and taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a building equipped with a HVAC system, accordingto an exemplary embodiment.

FIG. 2 is a block diagram of a waterside system that may be used inconjunction with the building of FIG. 1, according to an exemplaryembodiment.

FIG. 3 is a block diagram of an airside system that may be used inconjunction with the building of FIG. 1, according to an exemplaryembodiment.

FIG. 4 is a block diagram of a building management system (BMS) that maybe used to monitor and/or control the building of FIG. 1, according toan exemplary embodiment.

FIG. 5A is a block diagram illustrating a communication circuit incommunication with a host device, according to some embodiments.

FIG. 5B is a block diagram illustrating the flow of data from anexternal network to the communication circuit of FIG. 5A, according tosome embodiments.

FIG. 5C is a block diagram illustrating the flow of data from thecommunication circuit of FIG. 5A to an external network, according tosome embodiments.

FIG. 6A is a block diagram illustrating a mapping between attributes ofan equipment objects and a number of standard BACnet point objects,according to some embodiments.

FIG. 6B is a flow chart illustrating a process for communicating with aBMS device over a network using the communication circuit of FIG. 5A.

FIG. 7 is a schematic block diagram of the communication circuit of FIG.5A, according to some embodiments.

FIG. 8 is a sequence diagram illustrating an exemplary startup sequence,according to some embodiments.

FIG. 9 is a sequence diagram illustrating a process for transferringdata between a communication circuit and a host device, according tosome embodiments.

FIG. 10 is a sequence diagram illustrating a communication updateprocess, according to some embodiments.

FIG. 11 is a sequence diagram illustrating a communication circuitrestart process, according to some embodiments.

FIG. 12 is a sequence diagram illustrating a static_data process,according to some embodiments.

FIG. 13 is a flow chart illustrating a process for addressing thecommunication circuit, according to some embodiments.

FIG. 14 is a drawing of an actuator for use in an HVAC system to controlan HVAC component, according to some embodiments.

FIG. 15 is a block diagram illustrating a communication circuit incommunication with the actuator of FIG. 14, according to someembodiments.

FIG. 16 is a block diagram illustrating the flow of data from anexternal network to the communication circuit of FIG. 15, according tosome embodiments.

FIG. 17 is a block diagram illustrating the flow of data from thecommunication circuit of FIG. 15 to an external network, according tosome embodiments.

FIG. 18 is a block diagram illustrating a mapping between attributes ofan equipment object associated with the actuator of FIG. 15 and a numberof standard BACnet point objects, according to some embodiments.

FIGS. 19-20 are drawings of a chiller for use in an HVAC system,according to some embodiments.

FIG. 21 is a block diagram illustrating a communication circuit incommunication with the chiller of FIGS. 19-20, according to someembodiments.

FIG. 22 is a block diagram illustrating the flow of data from anexternal network to the communication circuit of FIG. 21, according tosome embodiments.

FIG. 23 is a block diagram illustrating the flow of data from thecommunication circuit of FIG. 21 to an external network, according tosome embodiments.

FIG. 24 is a block diagram illustrating a mapping between attributes ofan equipment object associated with the chiller of FIGS. 19-20 and anumber of standard BACnet point objects, according to some embodiments.

FIG. 25 is a block diagram illustrating a configuration system forconfiguring a communication circuit, according to some embodiments.

FIG. 26 is a flow chart illustrating a process for configuring acommunications circuit using the communication system of FIG. 25,according to some embodiments.

FIGS. 27-29 are exemplary user interface screens for a configurationwizard user interface, according to some embodiments.

DETAILED DESCRIPTION

Referring generally to the FIGURES, systems, devices and methods forintegrating BMS devices into a BMS network are described, according tovarious exemplary embodiments. The devices, systems and methodsdescribed herein may be used to integrate one or more network devicesonto a BMS network such as BACnet. A communication circuit may be usedto provide the communication with the BMS device. The communicationcircuit can include a device interface for interfacing with the BMSdevice and a network interface for interfacing with a network. Thecommunication circuit may communicate with the host device via acommunication interface, such as a universal asynchronousreceiver/transmitter. The device interface may have an equipment objectwhich can include all of the desired parameters from the BMS device.Data associated with the BMS device may be provided to the equipmentobject via the communication interface. The equipment object may allowfor the network interface to map standard network objects to theattributes in the equipment object.

Building Management System and HVAC System

Referring now to FIGS. 1-4, an exemplary building management system(BMS) and HVAC system in which the systems and methods of the presentinvention may be implemented are shown, according to an exemplaryembodiment. Referring particularly to FIG. 1, a perspective view of abuilding 10 is shown. Building 10 is served by a BMS. A BMS is, ingeneral, a system of devices configured to control, monitor, and manageequipment in or around a building or building area. A BMS can include,for example, an HVAC system, a security system, a lighting system, afire alerting system, or any other system that is capable of managingbuilding functions or devices, or any combination thereof.

The BMS that serves building 10 includes an HVAC system 100. HVAC system100 may include a plurality of HVAC devices (e.g., heaters, chillers,air handling units, pumps, fans, thermal energy storage, etc.)configured to provide heating, cooling, ventilation, or other servicesfor building 10. For example, HVAC system 100 is shown to include awaterside system 120 and an airside system 130. Waterside system 120 mayprovide a heated or chilled fluid to an air handling unit of airsidesystem 130. Airside system 130 may use the heated or chilled fluid toheat or cool an airflow provided to building 10. An exemplary watersidesystem and airside system which may be used in HVAC system 100 aredescribed in greater detail with reference to FIGS. 2-3.

HVAC system 100 is shown to include a chiller 102, a boiler 104, and arooftop air handling unit (AHU) 106. Waterside system 120 may use boiler104 and chiller 102 to heat or cool a working fluid (e.g., water,glycol, etc.) and may circulate the working fluid to AHU 106. In variousembodiments, the HVAC devices of waterside system 120 may be located inor around building 10 (as shown in FIG. 1) or at an offsite locationsuch as a central plant (e.g., a chiller plant, a steam plant, a heatplant, etc.). The working fluid may be heated in boiler 104 or cooled inchiller 102, depending on whether heating or cooling is required inbuilding 10. Boiler 104 may add heat to the circulated fluid, forexample, by burning a combustible material (e.g., natural gas) or usingan electric heating element. Chiller 102 may place the circulated fluidin a heat exchange relationship with another fluid (e.g., a refrigerant)in a heat exchanger (e.g., an evaporator) to absorb heat from thecirculated fluid. The working fluid from chiller 102 and/or boiler 104may be transported to AHU 106 via piping 108.

AHU 106 may place the working fluid in a heat exchange relationship withan airflow passing through AHU 106 (e.g., via one or more stages ofcooling coils and/or heating coils). The airflow may be, for example,outside air, return air from within building 10, or a combination ofboth. AHU 106 may transfer heat between the airflow and the workingfluid to provide heating or cooling for the airflow. For example, AHU106 may include one or more fans or blowers configured to pass theairflow over or through a heat exchanger containing the working fluid.The working fluid may then return to chiller 102 or boiler 104 viapiping 110.

Airside system 130 may deliver the airflow supplied by AHU 106 (i.e.,the supply airflow) to building 10 via air supply ducts 112 and mayprovide return air from building 10 to AHU 106 via air return ducts 114.In some embodiments, airside system 130 includes multiple variable airvolume (VAV) units 116. For example, airside system 130 is shown toinclude a separate VAV unit 116 on each floor or zone of building 10.VAV units 116 may include dampers or other flow control elements thatcan be operated to control an amount of the supply airflow provided toindividual zones of building 10. In other embodiments, airside system130 delivers the supply airflow into one or more zones of building 10(e.g., via supply ducts 112) without using intermediate VAV units 116 orother flow control elements. AHU 106 may include various sensors (e.g.,temperature sensors, pressure sensors, etc.) configured to measureattributes of the supply airflow. AHU 106 may receive input from sensorslocated within AHU 106 and/or within the building zone and may adjustthe flow rate, temperature, or other attributes of the supply airflowthrough AHU 106 to achieve setpoint conditions for the building zone.

Referring now to FIG. 2, a block diagram of a waterside system 200 isshown, according to some embodiments. In various embodiments, watersidesystem 200 may supplement or replace waterside system 120 in HVAC system100 or may be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, waterside system 200 may include asubset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller102, pumps, valves, etc.) and may operate to supply a heated or chilledfluid to AHU 106. The HVAC devices of waterside system 200 may belocated within building 10 (e.g., as components of waterside system 120)or at an offsite location such as a central plant.

In FIG. 2, waterside system 200 is shown as a central plant having aplurality of subplants 202-212. Subplants 202-212 are shown to include aheater subplant 202, a heat recovery chiller subplant 204, a chillersubplant 206, a cooling tower subplant 208, a hot thermal energy storage(TES) subplant 210, and a cold thermal energy storage (TES) subplant212. Subplants 202-212 consume resources (e.g., water, natural gas,electricity, etc.) from utilities to serve the thermal energy loads(e.g., hot water, cold water, heating, cooling, etc.) of a building orcampus. For example, heater subplant 202 may be configured to heat waterin a hot water loop 214 that circulates the hot water between heatersubplant 202 and building 10. Chiller subplant 206 may be configured tochill water in a cold water loop 216 that circulates the cold waterbetween the chiller subplant 206 and the building 10. Heat recoverychiller subplant 204 may be configured to transfer heat from cold waterloop 216 to hot water loop 214 to provide additional heating for the hotwater and additional cooling for the cold water. Condenser water loop218 may absorb heat from the cold water in chiller subplant 206 andreject the absorbed heat in cooling tower subplant 208 or transfer theabsorbed heat to hot water loop 214. Hot TES subplant 210 and cold TESsubplant 212 may store hot and cold thermal energy, respectively, forsubsequent use.

Hot water loop 214 and cold water loop 216 may deliver the heated and/orchilled water to air handlers located on the rooftop of building 10(e.g., AHU 106) or to individual floors or zones of building 10 (e.g.,VAV units 116). The air handlers push air past heat exchangers (e.g.,heating coils or cooling coils) through which the water flows to provideheating or cooling for the air. The heated or cooled air may bedelivered to individual zones of building 10 to serve the thermal energyloads of building 10. The water then returns to subplants 202-212 toreceive further heating or cooling.

Although subplants 202-212 are shown and described as heating andcooling water for circulation to a building, it is understood that anyother type of working fluid (e.g., glycol, CO2, etc.) may be used inplace of or in addition to water to serve the thermal energy loads. Inother embodiments, subplants 202-212 may provide heating and/or coolingdirectly to the building or campus without requiring an intermediateheat transfer fluid. These and other variations to waterside system 200are within the teachings of the present invention.

Each of subplants 202-212 may include a variety of equipment configuredto facilitate the functions of the subplant. For example, heatersubplant 202 is shown to include a plurality of heating elements 220(e.g., boilers, electric heaters, etc.) configured to add heat to thehot water in hot water loop 214. Heater subplant 202 is also shown toinclude several pumps 222 and 224 configured to circulate the hot waterin hot water loop 214 and to control the flow rate of the hot waterthrough individual heating elements 220. Chiller subplant 206 is shownto include a plurality of chillers 232 configured to remove heat fromthe cold water in cold water loop 216. Chiller subplant 206 is alsoshown to include several pumps 234 and 236 configured to circulate thecold water in cold water loop 216 and to control the flow rate of thecold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality ofheat recovery heat exchangers 226 (e.g., refrigeration circuits)configured to transfer heat from cold water loop 216 to hot water loop214. Heat recovery chiller subplant 204 is also shown to include severalpumps 228 and 230 configured to circulate the hot water and/or coldwater through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226.Cooling tower subplant 208 is shown to include a plurality of coolingtowers 238 configured to remove heat from the condenser water incondenser water loop 218. Cooling tower subplant 208 is also shown toinclude several pumps 240 configured to circulate the condenser water incondenser water loop 218 and to control the flow rate of the condenserwater through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configuredto store the hot water for later use. Hot TES subplant 210 may alsoinclude one or more pumps or valves configured to control the flow rateof the hot water into or out of hot TES tank 242. Cold TES subplant 212is shown to include cold TES tanks 244 configured to store the coldwater for later use. Cold TES subplant 212 may also include one or morepumps or valves configured to control the flow rate of the cold waterinto or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200(e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines inwaterside system 200 include an isolation valve associated therewith.Isolation valves may be integrated with the pumps or positioned upstreamor downstream of the pumps to control the fluid flows in watersidesystem 200. In various embodiments, waterside system 200 may includemore, fewer, or different types of devices and/or subplants based on theparticular configuration of waterside system 200 and the types of loadsserved by waterside system 200.

Referring now to FIG. 3, a block diagram of an airside system 300 isshown, according to an exemplary embodiment. In various embodiments,airside system 300 may supplement or replace airside system 130 in HVACsystem 100 or may be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, airside system 300 may include a subsetof the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116,ducts 112-114, fans, dampers, etc.) and may be located in or aroundbuilding 10. Airside system 300 may operate to heat or cool an airflowprovided to building 10 using a heated or chilled fluid provided bywaterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type airhandling unit (AHU) 302. Economizer-type AHUs vary the amount of outsideair and return air used by the air handling unit for heating or cooling.For example, AHU 302 may receive return air 304 from building zone 306via return air duct 308 and may deliver supply air 310 to building zone306 via supply air duct 312. In some embodiments, AHU 302 is a rooftopunit located on the roof of building 10 (e.g., AHU 106 as shown inFIG. 1) or otherwise positioned to receive both return air 304 andoutside air 314. AHU 302 may be configured to operate exhaust air damper316, mixing damper 318, and outside air damper 320 to control an amountof outside air 314 and return air 304 that combine to form supply air310. Any return air 304 that does not pass through mixing damper 318 maybe exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 may be operated by an actuator. For example,exhaust air damper 316 may be operated by actuator 324, mixing damper318 may be operated by actuator 326, and outside air damper 320 may beoperated by actuator 328. Actuators 324-328 may communicate with an AHUcontroller 330 via a communications link 332. Actuators 324-328 mayreceive control signals from AHU controller 330 and may provide feedbacksignals to AHU controller 330. Feedback signals may include, forexample, an indication of a current actuator or damper position, anamount of torque or force exerted by the actuator, diagnosticinformation (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configurationsettings, calibration data, and/or other types of information or datathat may be collected, stored, or used by actuators 324-328. AHUcontroller 330 may be an economizer controller configured to use one ormore control algorithms (e.g., state-based algorithms, extremum seekingcontrol (ESC) algorithms, proportional-integral (PI) control algorithms,proportional-integral-derivative (PID) control algorithms, modelpredictive control (MPC) algorithms, feedback control algorithms, etc.)to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil334, a heating coil 336, and a fan 338 positioned within supply air duct312. Fan 338 may be configured to force supply air 310 through coolingcoil 334 and/or heating coil 336 and provide supply air 310 to buildingzone 306. AHU controller 330 may communicate with fan 338 viacommunications link 340 to control a flow rate of supply air 310. Insome embodiments, AHU controller 330 controls an amount of heating orcooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 may receive a chilled fluid from waterside system 200(e.g., from cold water loop 216) via piping 342 and may return thechilled fluid to waterside system 200 via piping 344. Valve 346 may bepositioned along piping 342 or piping 344 to control a flow rate of thechilled fluid through cooling coil 334. In some embodiments, coolingcoil 334 includes multiple stages of cooling coils that can beindependently activated and deactivated (e.g., by AHU controller 330, byBMS controller 366, etc.) to modulate an amount of cooling applied tosupply air 310.

Heating coil 336 may receive a heated fluid from waterside system 200(e.g., from hot water loop 214) via piping 348 and may return the heatedfluid to waterside system 200 via piping 350. Valve 352 may bepositioned along piping 348 or piping 350 to control a flow rate of theheated fluid through heating coil 336. In some embodiments, heating coil336 includes multiple stages of heating coils that can be independentlyactivated and deactivated (e.g., by AHU controller 330, by BMScontroller 366, etc.) to modulate an amount of heating applied to supplyair 310.

Each of valves 346 and 352 may be controlled by an actuator. Forexample, valve 346 may be controlled by actuator 354 and valve 352 maybe controlled by actuator 356. Actuators 354-356 may communicate withAHU controller 330 via communications links 358-360. Actuators 354-356may receive control signals from AHU controller 330 and may providefeedback signals to controller 330. In some embodiments, AHU controller330 receives a measurement of the supply air temperature from atemperature sensor 362 positioned in supply air duct 312 (e.g.,downstream of cooling coil 334 and/or heating coil 336). AHU controller330 may also receive a measurement of the temperature of building zone306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 viaactuators 354-356 to modulate an amount of heating or cooling providedto supply air 310 (e.g., to achieve a setpoint temperature for supplyair 310 or to maintain the temperature of supply air 310 within asetpoint temperature range). The positions of valves 346 and 352 affectthe amount of heating or cooling provided to supply air 310 by coolingcoil 334 or heating coil 336 and may correlate with the amount of energyconsumed to achieve a desired supply air temperature. AHU 330 maycontrol the temperature of supply air 310 and/or building zone 306 byactivating or deactivating coils 334-336, adjusting a speed of fan 338,or a combination of both.

Still referring to FIG. 3, airside system 300 is shown to include abuilding management system (BMS) controller 366 and a client device 368.BMS controller 366 may include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers for airside system 300, waterside system200, HVAC system 100, and/or other controllable systems that servebuilding 10. BMS controller 366 may communicate with multiple downstreambuilding systems or subsystems (e.g., HVAC system 100, a securitysystem, a lighting system, waterside system 200, etc.) via acommunications link 370 according to like or disparate protocols (e.g.,LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMScontroller 366 may be separate (as shown in FIG. 3) or integrated. In anintegrated implementation, AHU controller 330 may be a software moduleconfigured for execution by a processor of BMS controller 366.

In some embodiments, AHU controller 330 receives information from BMScontroller 366 (e.g., commands, setpoints, operating boundaries, etc.)and provides information to BMS controller 366 (e.g., temperaturemeasurements, valve or actuator positions, operating statuses,diagnostics, etc.). For example, AHU controller 330 may provide BMScontroller 366 with temperature measurements from temperature sensors362-364, equipment on/off states, equipment operating capacities, and/orany other information that can be used by BMS controller 366 to monitoror control a variable state or condition within building zone 306.

Client device 368 may include one or more human-machine interfaces orclient interfaces (e.g., graphical user interfaces, reportinginterfaces, text-based computer interfaces, client-facing web services,web servers that provide pages to web clients, etc.) for controlling,viewing, or otherwise interacting with HVAC system 100, its subsystems,and/or devices. Client device 368 may be a computer workstation, aclient terminal, a remote or local interface, or any other type of userinterface device. Client device 368 may be a stationary terminal or amobile device. For example, client device 368 may be a desktop computer,a computer server with a user interface, a laptop computer, a tablet, asmartphone, a PDA, or any other type of mobile or non-mobile device.Client device 368 may communicate with BMS controller 366 and/or AHUcontroller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a building management system(BMS) 400 is shown, according to an exemplary embodiment. BMS 400 may beimplemented in building 10 to automatically monitor and control variousbuilding functions. BMS 400 is shown to include BMS controller 366 and aplurality of building subsystems 428. Building subsystems 428 are shownto include a building electrical subsystem 434, an informationcommunication technology (ICT) subsystem 436, a security subsystem 438,a HVAC subsystem 440, a lighting subsystem 442, a lift/escalatorssubsystem 432, and a fire safety subsystem 430. In various embodiments,building subsystems 428 can include fewer, additional, or alternativesubsystems. For example, building subsystems 428 may also oralternatively include a refrigeration subsystem, an advertising orsignage subsystem, a cooking subsystem, a vending subsystem, a printeror copy service subsystem, or any other type of building subsystem thatuses controllable equipment and/or sensors to monitor or controlbuilding 10. In some embodiments, building subsystems 428 includewaterside system 200 and/or airside system 300, as described withreference to FIGS. 2-3.

Each of building subsystems 428 may include any number of devices,controllers, and connections for completing its individual functions andcontrol activities. HVAC subsystem 440 may include many of the samecomponents as HVAC system 100, as described with reference to FIGS. 1-3.For example, HVAC subsystem 440 may include a chiller, a boiler, anynumber of air handling units, economizers, field controllers,supervisory controllers, actuators, temperature sensors, and otherdevices for controlling the temperature, humidity, airflow, or othervariable conditions within building 10. Lighting subsystem 442 mayinclude any number of light fixtures, ballasts, lighting sensors,dimmers, or other devices configured to controllably adjust the amountof light provided to a building space. Security subsystem 438 mayinclude occupancy sensors, video surveillance cameras, digital videorecorders, video processing servers, intrusion detection devices, accesscontrol devices and servers, or other security-related devices.

Still referring to FIG. 4, BMS controller 366 is shown to include acommunications interface 407 and a BMS interface 409. Interface 407 mayfacilitate communications between BMS controller 366 and externalapplications (e.g., monitoring and reporting applications 422,enterprise control applications 426, remote systems and applications444, applications residing on client devices 448, etc.) for allowinguser control, monitoring, and adjustment to BMS controller 366 and/orsubsystems 428. Interface 407 may also facilitate communications betweenBMS controller 366 and client devices 448. BMS interface 409 mayfacilitate communications between BMS controller 366 and buildingsubsystems 428 (e.g., HVAC, lighting security, lifts, powerdistribution, business, etc.).

Interfaces 407, 409 can be or include wired or wireless communicationsinterfaces (e.g., jacks, antennas, transmitters, receivers,transceivers, wire terminals, etc.) for conducting data communicationswith building subsystems 428 or other external systems or devices. Invarious embodiments, communications via interfaces 407, 409 may bedirect (e.g., local wired or wireless communications) or via acommunications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 407, 409 can include an Ethernetcard and port for sending and receiving data via an Ethernet-basedcommunications link or network. In another example, interfaces 407, 409can include a WiFi transceiver for communicating via a wirelesscommunications network. In another example, one or both of interfaces407, 409 may include cellular or mobile phone communicationstransceivers. In one embodiment, communications interface 407 is a powerline communications interface and BMS interface 409 is an Ethernetinterface. In other embodiments, both communications interface 407 andBMS interface 409 are Ethernet interfaces or are the same Ethernetinterface.

Still referring to FIG. 4, BMS controller 366 is shown to include aprocessing circuit 404 including a processor 406 and memory 408.Processing circuit 404 may be communicably connected to BMS interface409 and/or communications interface 407 such that processing circuit 404and the various components thereof can send and receive data viainterfaces 407, 409. Processor 406 can be implemented as a generalpurpose processor, an application specific integrated circuit (ASIC),one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable electronic processingcomponents.

Memory 408 (e.g., memory, memory unit, storage device, etc.) may includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 408 may be or include volatile memory ornon-volatile memory. Memory 408 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to anexemplary embodiment, memory 408 is communicably connected to processor406 via processing circuit 404 and includes computer code for executing(e.g., by processing circuit 404 and/or processor 406) one or moreprocesses described herein.

In some embodiments, BMS controller 366 is implemented within a singlecomputer (e.g., one server, one housing, etc.). In various otherembodiments BMS controller 366 may be distributed across multipleservers or computers (e.g., that can exist in distributed locations).Further, while FIG. 4 shows applications 422 and 426 as existing outsideof BMS controller 366, in some embodiments, applications 422 and 426 maybe hosted within BMS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterpriseintegration layer 410, an automated measurement and validation (AM&V)layer 412, a demand response (DR) layer 414, a fault detection anddiagnostics (FDD) layer 416, an integrated control layer 418, and abuilding subsystem integration later 420. Layers 410-420 may beconfigured to receive inputs from building subsystems 428 and other datasources, determine optimal control actions for building subsystems 428based on the inputs, generate control signals based on the optimalcontrol actions, and provide the generated control signals to buildingsubsystems 428. The following paragraphs describe some of the generalfunctions performed by each of layers 410-420 in BMS 400.

Enterprise integration layer 410 may be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 426 may be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 426 may also oralternatively be configured to provide configuration GUIs forconfiguring BMS controller 366. In yet other embodiments, enterprisecontrol applications 426 can work with layers 410-420 to optimizebuilding performance (e.g., efficiency, energy use, comfort, or safety)based on inputs received at interface 407 and/or BMS interface 409.

Building subsystem integration layer 420 may be configured to managecommunications between BMS controller 366 and building subsystems 428.For example, building subsystem integration layer 420 may receive sensordata and input signals from building subsystems 428 and provide outputdata and control signals to building subsystems 428. Building subsystemintegration layer 420 may also be configured to manage communicationsbetween building subsystems 428. Building subsystem integration layer420 translate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Demand response layer 414 may be configured to optimize resource usage(e.g., electricity use, natural gas use, water use, etc.) and/or themonetary cost of such resource usage in response to satisfy the demandof building 10. The optimization may be based on time-of-use prices,curtailment signals, energy availability, or other data received fromutility providers, distributed energy generation systems 424, fromenergy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or fromother sources. Demand response layer 414 may receive inputs from otherlayers of BMS controller 366 (e.g., building subsystem integration layer420, integrated control layer 418, etc.). The inputs received from otherlayers may include environmental or sensor inputs such as temperature,carbon dioxide levels, relative humidity levels, air quality sensoroutputs, occupancy sensor outputs, room schedules, and the like. Theinputs may also include inputs such as electrical use (e.g., expressedin kWh), thermal load measurements, pricing information, projectedpricing, smoothed pricing, curtailment signals from utilities, and thelike.

According to an exemplary embodiment, demand response layer 414 includescontrol logic for responding to the data and signals it receives. Theseresponses can include communicating with the control algorithms inintegrated control layer 418, changing control strategies, changingsetpoints, or activating/deactivating building equipment or subsystemsin a controlled manner. Demand response layer 414 may also includecontrol logic configured to determine when to utilize stored energy. Forexample, demand response layer 414 may determine to begin using energyfrom energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control moduleconfigured to actively initiate control actions (e.g., automaticallychanging setpoints) which minimize energy costs based on one or moreinputs representative of or based on demand (e.g., price, a curtailmentsignal, a demand level, etc.). In some embodiments, demand responselayer 414 uses equipment models to determine an optimal set of controlactions. The equipment models may include, for example, thermodynamicmodels describing the inputs, outputs, and/or functions performed byvarious sets of building equipment. Equipment models may representcollections of building equipment (e.g., subplants, chiller arrays,etc.) or individual devices (e.g., individual chillers, heaters, pumps,etc.).

Demand response layer 414 may further include or draw upon one or moredemand response policy definitions (e.g., databases, XML files, etc.).The policy definitions may be edited or adjusted by a user (e.g., via agraphical user interface) so that the control actions initiated inresponse to demand inputs may be tailored for the user's application,desired comfort level, particular building equipment, or based on otherconcerns. For example, the demand response policy definitions canspecify which equipment may be turned on or off in response toparticular demand inputs, how long a system or piece of equipment shouldbe turned off, what setpoints can be changed, what the allowable setpoint adjustment range is, how long to hold a high demand setpointbefore returning to a normally scheduled setpoint, how close to approachcapacity limits, which equipment modes to utilize, the energy transferrates (e.g., the maximum rate, an alarm rate, other rate boundaryinformation, etc.) into and out of energy storage devices (e.g., thermalstorage tanks, battery banks, etc.), and when to dispatch on-sitegeneration of energy (e.g., via fuel cells, a motor generator set,etc.).

Integrated control layer 418 may be configured to use the data input oroutput of building subsystem integration layer 420 and/or demandresponse later 414 to make control decisions. Due to the subsystemintegration provided by building subsystem integration layer 420,integrated control layer 418 can integrate control activities of thesubsystems 428 such that the subsystems 428 behave as a singleintegrated supersystem. In an exemplary embodiment, integrated controllayer 418 includes control logic that uses inputs and outputs from aplurality of building subsystems to provide greater comfort and energysavings relative to the comfort and energy savings that separatesubsystems could provide alone. For example, integrated control layer418 may be configured to use an input from a first subsystem to make anenergy-saving control decision for a second subsystem. Results of thesedecisions can be communicated back to building subsystem integrationlayer 420.

Integrated control layer 418 is shown to be logically below demandresponse layer 414. Integrated control layer 418 may be configured toenhance the effectiveness of demand response layer 414 by enablingbuilding subsystems 428 and their respective control loops to becontrolled in coordination with demand response layer 414. Thisconfiguration may advantageously reduce disruptive demand responsebehavior relative to conventional systems. For example, integratedcontrol layer 418 may be configured to assure that a demandresponse-driven upward adjustment to the setpoint for chilled watertemperature (or another component that directly or indirectly affectstemperature) does not result in an increase in fan energy (or otherenergy used to cool a space) that would result in greater total buildingenergy use than was saved at the chiller.

Integrated control layer 418 may be configured to provide feedback todemand response layer 414 so that demand response layer 414 checks thatconstraints (e.g., temperature, lighting levels, etc.) are properlymaintained even while demanded load shedding is in progress. Theconstraints may also include setpoint or sensed boundaries relating tosafety, equipment operating limits and performance, comfort, fire codes,electrical codes, energy codes, and the like. Integrated control layer418 is also logically below fault detection and diagnostics layer 416and automated measurement and validation layer 412. Integrated controllayer 418 may be configured to provide calculated inputs (e.g.,aggregations) to these higher levels based on outputs from more than onebuilding subsystem.

Automated measurement and validation (AM&V) layer 412 may be configuredto verify that control strategies commanded by integrated control layer418 or demand response layer 414 are working properly (e.g., using dataaggregated by AM&V layer 412, integrated control layer 418, buildingsubsystem integration layer 420, FDD layer 416, or otherwise). Thecalculations made by AM&V layer 412 may be based on building systemenergy models and/or equipment models for individual BMS devices orsubsystems. For example, AM&V layer 412 may compare a model-predictedoutput with an actual output from building subsystems 428 to determinean accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 may be configured toprovide on-going fault detection for building subsystems 428, buildingsubsystem devices (i.e., building equipment), and control algorithmsused by demand response layer 414 and integrated control layer 418. FDDlayer 416 may receive data inputs from integrated control layer 418,directly from one or more building subsystems or devices, or fromanother data source. FDD layer 416 may automatically diagnose andrespond to detected faults. The responses to detected or diagnosedfaults may include providing an alert message to a user, a maintenancescheduling system, or a control algorithm configured to attempt torepair the fault or to work-around the fault.

FDD layer 416 may be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., loose damper linkage)using detailed subsystem inputs available at building subsystemintegration layer 420. In other exemplary embodiments, FDD layer 416 isconfigured to provide “fault” events to integrated control layer 418which executes control strategies and policies in response to thereceived fault events. According to an exemplary embodiment, FDD layer416 (or a policy executed by an integrated control engine or businessrules engine) may shut-down systems or direct control activities aroundfaulty devices or systems to reduce energy waste, extend equipment life,or assure proper control response.

FDD layer 416 may be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer416 may use some content of the data stores to identify faults at theequipment level (e.g., specific chiller, specific AHU, specific terminalunit, etc.) and other content to identify faults at component orsubsystem levels. For example, building subsystems 428 may generatetemporal (i.e., time-series) data indicating the performance of BMS 400and the various components thereof. The data generated by buildingsubsystems 428 may include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or process (e.g., a temperature control process, aflow control process, etc.) is performing in terms of error from itssetpoint. These processes can be examined by FDD layer 416 to exposewhen the system begins to degrade in performance and alert a user torepair the fault before it becomes more severe.

Communications Circuit

Referring now to FIG. 5A, a block diagram illustrating a communicationscircuit 500 in communication with a host controller 502 is shown,according to some embodiments. In one embodiment, the host controller502 and the communications circuit 500 are contained within a BMS device503. The BMS device 503 can be any number of devices, including any ofthe BMS devices listed above. In one embodiment, the BMS device 503 isan HVAC device, such as a chiller, an actuator, a valve, an AHU, an RTU,a boiler, etc. The host controller 502 may be a proprietary devicespecific to the BMS device 503, and used to control the BMS device 503.As shown in FIG. 5A, both the communications circuit 500 and the hostcontroller 502 are located within the BMS device 503. In someembodiments, the communications circuit 500 is an integrated circuit,chip, or microcontroller unit (MCU) separate from a processing circuitof the host controller 502, and configured to bridge communicationsbetween the host controller 502 and other external systems or devices.In other embodiments, the communications circuit 500 is a separatecircuit board (daughter board) containing the required circuitry,located within the BMS device 503, and in communication with the hostcontroller 502. In a further embodiment, the communications circuit 500is a separate device coupled to the BMS device 503, and in communicationwith the host controller 502. This may allow for a communicationscircuit 500 to be installed on a BMS device 503 to allow for a BMSdevice 503 without network connectivity to be easily converted tocommunicate via a BMS network, such as BACnet.

The communications circuit 500 can be configured to support a variety ofdata communications between the host controller 502 and other externalsystems or devices via a network 504. As illustrated in FIG. 5A, othersystems or devices can include controllers 506, enterprise controlapplications 508, client devices 510, remote systems and applications512 and/or monitoring and reporting applications 514. The communicationscircuit 500 can be a wired or wireless communication link and may useany of a variety of disparate communications protocols (e.g., BACnet,LON, WiFi, Bluetooth, TCP/IP, etc.) to communicate with the network 504and/or directly to other external systems or devices. In someembodiments, the communications circuit 500 is the Johnson ControlsBACnet on a Chip (JBOC) product. For example, the communications circuit500 can be a pre-certified BACnet communication circuit capable ofcommunicating on a building automation and controls network (BACnet)using a master/slave token passing (MSTP) protocol. The communicationscircuit 500 can be added to any existing host device with acommunication interface to enable BACnet communication with minimalsoftware and hardware design effort. In other words, communicationscircuit 500 provides a provides a BACnet interface for the hostcontroller 502.

The communications circuit 500 is shown to include a device interface516 and a network interface 518. In one embodiment, the networkinterface 518 is a BACnet interface. The device interface 516 caninclude an equipment object 520, a communications task (e.g., a JBOCtask) 522, and a universal asynchronous receiver/transmitter (UART)interface 524. The UART interface 524 can be configured to communicatewith a corresponding host UART interface 526 of the host controller 502using a UART protocol. In other examples, the UART interfaces 524, 526can be replaced with serial peripheral interfaces (SPI) orinter-integrated circuit (I2C) interfaces. In some embodiments, a levelshifter 528 device may be required to ensure that the signal levels fromthe host controller 502 are compatible with the UART 524 of the deviceinterface 516, and vice versa. In one example, the level shifter 528 canbe a TCA9406DCTR from Texas Instruments; however, other level shiftingdevices are contemplated.

The communication task module 522 can be connected to the UART interface524 via an application-program interface (API) 530 and can be configuredto populate the equipment object 520 with values received from theprocessing circuit 550 via the UART interfaces 524, 526. Thecommunications task module 522 can also read values of the equipmentobject 520 populated by the network interface 518 and can provide thevalues to the host controller 502. Similarly, the host UART interface526 can be connected to a host interface 532 via an API 531 and can beconfigured to communicate with a host application. In one embodiment,the host controller 502 sets the baud rate to be used for communicationbetween the host controller 502 and the communications circuit 500 usingthe UART interfaces 524, 526. In a further embodiment, the UARTinterfaces 524, 526 are configured to operate in a half-duplex mode.When the UART interfaces 524, 526 are configured in a half-duplex mode,one device will be responsible for initiating all commands. In oneembodiment, the host controller 502 is configured to communicate using ahalf-duplex mode wherein the host controller 502 will transmit allcommands, and the communications circuit 500 will only transmit acommand in response to a command transmitted by the host controller 502.This configuration provides the host controller 502 with total controlof the flow of data between the host controller 502 and thecommunications circuit 500. In other examples, the UART interfaces 524,526 can be configured to operate in full-duplex mode.

The equipment object 520 can be a proprietary equipment objectconfigured to expose host controller 502 data to the network interface518 as a single object with one or more associated attributes. In oneembodiment, the equipment object 520 maps the data received from thehost controller 502 into an associated attribute within the equipmentobject 520. Attributes of the equipment object 520 can be defined by auser (e.g., using a data definition tool) to expose any type of internalhost controller 502 data to the network interface 518. In oneembodiment, the host controller 502 instructs the communication circuit500 which attributes within the equipment object are to be exposed tothe network interface 518. For example, the host controller 502 mayprovide a master list of attributes to the equipment object 520 duringan initial setup. The host controller 502 may then instruct thecommunication circuit 500 to only expose a subset of attributes of theequipment object 520 from the master list of attributes to the networkinterface 518. In some embodiments, a user may select which attributesare to be exposed to the network interface 518 during the initialconfiguration of the BMS device 503. For example, the user may indicatewhich attributes are to be exposed to the network interface 18 using aconfiguration tool, as described in more detail below. In otherembodiments, the host controller 502 may automatically determine whichattributes are to be exposed to the network interface 518 based on thedata type. For example, the host controller 502 may instruct thecommunication circuit 500 not to expose “static” data of the BMS device503, as described in more detail below.

The network interface 518 may read the attributes of the equipmentobject 520 and map the attributes of the equipment object 520 to networkobjects, such as BACnet objects 533 via a mapping module 534. In someembodiments, the network interface 518 may only map those attributesthat are selected to be exposed to the network objects 533 by the hostcontroller 502. Example BACnet objects may include: a file data object535, including read and/or write file services; a device data object 536(i.e. BACnet device object data); a binary value data object 538 (e.g.relay output states, switch positions, on/off device status); an analogvalue data object 540 (e.g. speed, temperature, flow, pressure, etc.),which can include analog value objects with or without priority; and amultistate value data object 542, which can include multistate valueobjects with or without priority. Additionally, other BACnet objects 533may include a structured view, a char string and an integer. In oneembodiment, the network interface 518 can be configured to write thevalues of the BACnet objects 533 to attributes of the equipment object520. The attribute values of the equipment object 520 can becommunicated to the host controller 502 via the UART interfaces 524,526and be used to operate the host controller 502.

Turning now to FIG. 6A, a block diagram illustrating a mapping betweenattributes of the equipment object 520, and a number BACnet objects 533is shown, according to some embodiments. In one example, the equipmentobject 600 and the BACnet objects 533 can be associated with a BMSdevice, such as a valve. However, the BACnet objects 533 can beassociated with any other BMS device type, as described above. As shownin FIG. 6A, the BACnet objects 533 include five standard BACnet pointobjects, including a setpoint object 602, a valve position object 604, aminimum stroke length object 606, a command position object 608, and astatus object 610. The setpoint object 602, the valve position object604, the minimum stroke object 606, and the command position object 608are shown as analog data objects. The status object 610 is shown as amultistate value data object. The attributes of the equipment object 520can be defined by a user (e.g., using a data definition tool) and mappedto various types of internal BMS device data. Additionally, the user candefine which of the attributes of the equipment object 520 to expose tothe network interface 518. As shown in FIG. 6A, the equipment object 520is shown to include a setpoint attribute 612, a valve position attribute614, a minimum stroke attribute 616, a command position attribute 618, astatus attribute 620 and a number commands attribute 622. As furthershown in FIG. 6A, the equipment object 600 is configured to expose thesetpoint attribute 612, the valve position attribute 614, the minimumstroke attribute 616, the command position attribute 618, and the statusattribute 620 to the respective BACnet objects 533. Further, theequipment model 600 is configured to not expose the number commandsattribute to a corresponding BACnet object. An equipment object 600attribute may not be exposed to keep certain attributes and/or dataproprietary. For example, diagnostic data may be kept proprietary andonly be allowed to be accessed via authorized commissioning tools.Alternatively, an equipment object attribute 600 may not be exposedwhere the data is static, as described above. The mapping module 534 mayread the attributes of the equipment object 520, and map them to theappropriate BACnet objects 533.

Returning to FIG. 5A, the host controller 502 can be configured tointerface with the attributes of the equipment object 520 in a moreconcise fashion than the standard BACnet point objects. For example, thehost controller 502 can read and write various items of internal hostcontroller data to the equipment object 520 as attribute values of theequipment object 520. The equipment object 520 can then expose thevalues of the attributes to the network interface 518, as describedabove. The mapping module 534 may then map the values of the exposedattributes to one or more of the BACnet objects 533. In one embodiment,the mapping module 534 evaluates parameters of the attributes of theequipment object 520, such as data type, attribute ID, whether theattribute is modifiable, etc. The mapping module 534 may then map theexposed attribute values of the equipment object 520 to the appropriateBACnet object 533 based on the evaluated parameters. In one embodiment,the mapping module 534 may continuously evaluate the attribute values inthe equipment object 520, and thereby continuously map the attributevalues to the BACnet objects 533. Alternatively, the equipment object520 may provide an interrupt signal to the mapping module when anattribute value has been modified. The mapping module 534, receiving theinterrupt, may then proceed to evaluate the attribute values in theequipment object 520, and map the attribute values to the BACnet objects533. In further examples, the mapping module 534 may evaluate theexposed attribute values at predetermined intervals. For example, themapping module 534 may evaluate the exposed attribute values in onesecond intervals. However, predetermined intervals of more than onesecond or less than one second are also contemplated. In someembodiments, the mapping module 534 may further be able to instruct thenetwork interface 518 to generate one or more BACnet objects 533 for oneor more exposed attributes within the equipment object 520. For example,once the equipment object 520 has been configured by a user, asdescribed above, the mapping module 534 may read the exposed attributesvia the network interface 518. For example, the mapping module 534 mayread parameters associated with the exposed attributes such as attributeID's, data types, whether the data is modifiable, object names, etc. Themapping module 534 may then instruct the network interface 518 togenerate one or more BACnet attributes of the required type (e.g.analog, binary, multistate, etc.) to receive the values associated withthe exposed equipment object 520 attributes.

Once the attributes of the equipment object 520 have been exposed to thenetwork interface 518, a BACnet/MSTP layer 544 may read the BACnetobjects 533. The BACnet/MSTP layer 544 can be configured to facilitateBACnet communications using the MSTP master protocol. For example, theBACnet/MSTP layer 544 can be configured to transmit and receivesegmented messages. In some embodiments, the BACnet/MSTP layer 544 mayonly transmit segmented messages to devices that subscribe to the BMSdevice 503 via a BACnet Subscription Service. In other embodiments, theBACnet/MSTP layer 544 may make the data values contained in the BACnetobjects 533 available to other devices or systems via the network 504.The BACnet/MSTP layer 544 can further be configured to automaticallydetermine a baud rate. In other example, the baud rate can be manuallyspecified in the BACnet/MSTP layer 544. In one embodiment, theBACnet/MSTP layer 544 is capable of operating at the following baudrates: 9600, 19200, 38400, and 76800. The BACnet/MSTP layer 544 mayfurther support duplicate address avoidance by keeping a second devicewith a duplicate address from interfering with existing traffic. In oneembodiment, the BACnet/MSTP layer 544 supports the maximum MSTPApplication Protocol Data Unit (APDU) size of 480 bytes. The BACnet/MSTPlayer 544 may allow for the transmission/reception of change of value(COV) command flags. In one embodiment, the BACnet/MSTP layer 544 canaccept and/or generate data packets bundling multiple COV's into asingle message. While FIG. 5 illustrates a BACnet/MSTP layer, it iscontemplated that other communication layers may be used in the networkinterface 518.

In one embodiment the BACnet/MSTP layer 544 reads the BACnet objects533, and transmits the values associated with the BACnet objects 533 tothe network 504, via a communication link 546 using BACnet communicationprotocols. The communication link 546 may be a wireless interface. Inone embodiment, the communication link 546 is a Wi-Fi (802.11x)interface. Other wireless interfaces such as Bluetooth, Near FieldCommunication (NFC), LoRa RF, Cellular (3G, 4G, LTE, CDMA, etc.),Zigbee, etc. may also be used as the network interface 518. In otherexamples, the network interface 518 may be a wired interface, such as anEthernet connections (CATS, CAT6, etc.), a serial connection (RS-232,RS-485), or other applicable wired communication interfaces.

In one embodiment, the network 504 is a cloud-based (i.e. hosted)server. The cloud-based server may allow for devices to access thenetwork via an internet connection. For example, one or more of thecontroller 506, the enterprise control applications 508, the clientdevices 510, the remote systems and applications 512, and the monitoringand reporting applications may access the network 504 via an internetconnection. In other embodiments, the network 504 can be an internal BMSnetwork, such as a BACnet network, wherein the network 504 can providecommunication between BMS devices in the BMS system. The network 504 canbe a closed network in some instances, thereby only allowing access tothe network 504 from within the BMS system. Alternatively, the network504 may be an open network, thereby allowing access from a user outsideof the BMS network.

In one embodiment, the communications circuit 500 communicates directlywith the controller 506 via a controller communication interface 548using the BACnet MSTP layer 544. The controller communication interface548 may be an isolated RS-485 serial connection. In other examples, thecontroller communication interface 548 may be a serial connection suchas RS-232, a wireless connection such as Wi-Fi (802.11x), Bluetooth,NFC, Zigbee, LoRa RF, cellular (3G, 4G, LTE, CDMA, etc.), or othercommunication system, as applicable. Further, the controllercommunication interface 548 may be a wired connection such as anEthernet connection (CATS, CAT6), a local area network (LAN), or otherwired connection, as applicable. In one embodiment, the controller 506is a BMS controller as described above in regards to FIGS. 1-4,described above. In some embodiments, the controller 506 receives datafrom the host controller 502 via the communications circuit 500 asdescribed above, and then communicates the data to the network 504.Alternatively, the controller 506 may directly communicate the data toother devices, such as the enterprise control applications 508, theclient devices 510, the remote systems and applications 512 and/or themonitoring and reporting applications 514. In some embodiments, both thecontroller 506 and the network 504 may receive data from thecommunications circuit 500. In one example, the controller 506 canmonitor a specific value, such as an analog value exposed to the analogvalue object 540. Further, the BMS controller may monitor any of theBACnet objects as required or desired by the user.

The host controller 502 may include a processing circuit 550. Theprocessing circuit may include a processor 552 and a memory 554. Theprocessor 552 may be a general purpose or specific purpose processor, anapplication specific integrated circuit (ASIC), one or more fieldprogrammable gate arrays (FPGAs), a group of processing components, orother suitable processing components. The processor 552 is configured toexecute computer code or instructions stored in the memory 554 orreceived from other computer readable media (e.g., CDROM, networkstorage, a remote server, etc.).

The memory 554 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 554 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 554 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 554 may becommunicably connected to the processor 552 via the processing circuit550 and may include computer code for executing (e.g., by the processor)one or more processes described herein. When the processor 552 executesinstructions stored in the memory 554, the processor 552 generallyconfigures the host controller 502 (and more particularly the processingcircuit 550) to complete such activities.

In one embodiment, the memory stores a host application 556. The hostapplication 556 can include the required application for operating thehost device. In one embodiment, the host application 556 can generateupdated values for the attributes of the equipment object 520, which canbe communicated to the device interface 516 via the UART interfaces 524,526, as described above. The host application 556 can include softwareto read and store data received by the host controller 502. For example,the host controller 502 may include sensors for detecting variousattributes of the host controller 502. Example sensors can includevoltage sensors, current sensors, temperature sensors, position sensors,pressure sensors, or other applicable sensors. The host application mayread and/or store the data from these sensors within the memory 554.Further, the host controller 502 may include other data such assetpoints, position commands, diagnostic data, etc., which the hostapplication 556 can further read and store in the memory 554.

The host application 556 can further receive data and/or commands forcontrolling the host controller 502. In one embodiment, the hostinterface 532 may receive data via the UART interface 526, andcommunicate the data to the host application 556. For example, thecontroller 506 may communicate with the communications circuit 500 andchange a setpoint within the analog value BACnet object 540. The networkinterface 518 can then modify the corresponding attribute in theequipment object 520, which can then be communicated to the host devicevia the UART interfaces 524, 526. The host interface 532 can thenreceive the data via the host API 531. The host interface 532 may beconfigured to convert the received data (e.g. the setpoint change) intoa format compatible with the host application 556. The host application556, receiving the data (setpoint change) can then implement thesetpoint change on the host controller 502. In some embodiments, thehost application 556 may receive inputs or commands directly from a userinterface (not shown) of the host controller 502. The host applicationcan then update any changes provided via the user interface in theequipment object 520 by communicating the changes to the host interface532. The host interface 532 may then communicate the changes to theequipment object 520 via the UART interfaces 524, 526.

The communications circuit 500 may further include a serial peripheralinterface (SPI) bus driver 558. The SPI bus driver 558 can be used todrive a peripheral port 560 on the communication circuit. In oneembodiment, the peripheral port 560 is a serial flash interface, such asa USB port, an SD or micro SD port, a compact flash (CF) port, etc. Theperipheral port 560 may further be a serial interface (RS-232, RS-485)for direct wired connection to a hardware device, such as acommissioning tool or a programming tool. The peripheral port 560 can beused to allow for communication directly with the communications circuit500. In some examples, the peripheral port 560 can be used to provide asoftware (SW) and/or a firmware (FW) update directly to thecommunications circuit 500. Further, the peripheral port 560 may beconfigured as a programming port, thereby allowing a user to directlyprogram the communication circuit. For example, a user may access thecommunications circuit 500 via the peripheral port 560 to program theattributes of the equipment object 520 that are to be exposed to thenetwork interface 518. In some examples, the peripheral port 560 can beused to provide additional memory, such as flash memory (SD, CF, etc.).The additional memory may be used to store data associated with the hostcontroller 502, such as historical data, alarm history, data logs, etc.

The communications circuit 500 may further include an indication device562. In one embodiment, the indication device 562 can include one ormore illumination devices, such as LEDs. However, the indication device562 can further include other illumination devices, auditory indicationdevices (speakers, buzzers), or a combination thereof. In oneembodiment, the indication device 562 provides a visual indication thatthe communication circuit is communicating with the network 504 and/orthe controller 506. Alternatively, the indication device 562 can providean indication that the communications circuit 500 is communicating withthe host controller 502. In a further embodiment, the indication device562 can provide an indication of a status of the communications circuit500. For example, the indication device 562 may present one color (e.g.green) when the communications circuit 500 is functioning properly, anda second color (e.g. red) when the communications circuit 500 is notfunctioning properly. Further, the indication device 562 may provide anindication of a status of the host controller 502 instead of, or inaddition to the communications circuit 500. In still further examples,the indication device 562 may provide a series of visual and/or audibleoutputs in a repeating pattern that may represent a certain faultcurrently experienced by the communications circuit 500 and/or the hostcontroller 502.

Turning now to FIG. 5B, a block diagram illustrating the flow of datafrom the network 504 and/or the controller 506 to the communicationscircuit 500 is shown, according to some embodiments. As shown in FIG.5B, network 504 is a BACnet network; however, other networks arecontemplated. The network 504 and/or the controller 506 may provideBACnet data to the communications circuit 500. The BACnet data may bereceived by the BACnet/MSTP layer 544. The BACnet/MSTP layer 544 mayparse the received BACnet data. In one example, the BACnet/MSTP layer544 may parse the received BACnet data to isolated data associated withone or more BACnet Objects 533. For example, the BACnet/MSTP layer 544may first parse the data based on data type (analog, binary, multistate,etc.). The BACnet/MSTP layer 544 may then evaluate an ID associated withthe BACnet data to determine what BACnet object is associated with thereceived BACnet data. The BACnet/MSTP layer 544 may then transmit theparsed BACnet data to one or more BACnet objects 533 via the networkinterface. For example, the BACnet/MSTP layer 544 may transmit parsedanalog BACnet data to the analog BACnet object 540, parsed binary BACnetdata to the binary BACnet object 538, and parsed multistate BACnet datato the multistate BACnet object 542. This is exemplary only, as theremay be more BACnet object types available as described above. Further,multiples of each BACnet object type may further be provided. In oneembodiment, the BACnet/MSTP layer 544 can instruct the network interfaceto generate new BACnet objects when BACnet data is received that is notassociated with an existing BACnet object 533. The BACnet objects 533may then provide the associated BACnet Object data to the mapping module534. The mapping module 534 may then receive the BACnet Object data byquerying each of the BACnet objects to determine if a value had beenupdated. Alternatively, the BACnet objects may provide an interrupt, orother signal, to the mapping module 534 to instruct the mapping module534 to read a new BACnet object 533 value. The mapping module 534 maythen evaluate the received BACnet object data to determine whichattribute of the equipment object 520 the received BACnet object data isassociated with and transmit the data to the equipment object 520 asequipment object attribute data via the network interface 518. In oneembodiment, the mapping module 534 transmits equipment object attributedata for each of the one or more BACnet objects 533 to the equipmentobject 520 where the equipment object attributes associated with the oneor more BACnet objects are exposed to the network interface 518.Similarly, the mapping module 534 may only transmit equipment objectattribute data to the equipment object 520 where the associatedequipment object attribute is a writeable attribute. As will bedescribed later, a user, via a configuration tool, can configureequipment object attributes that are exposed and/or writable.

The equipment object 520 may then transmit attribute values to thecommunication task module 522. The attribute values may contain theattribute ID, as well as the data type and value. Alternatively, theattribute values may only contain the value associated with theattribute. In some embodiments, the communication task module 522 readsthe attribute values for the equipment object attributes, and determinesif any values have been changed. The communication task module 522,receiving the equipment object attribute values, may then convert theattribute values into one or more host controller serial data packets.The host controller serial data packets may be configured such that thedata packets are readable by the host device. The host controller datapackets may then be read by the UART 524 and converted into a UARTcompatible serial data packet. In one example, the API 530, as describedabove, may be used to convert the host control serial data packets intoUART compatible serial data packets. In other examples, the UART 524 mayconvert the attribute values into UART compatible serial data packetsitself. The UART 524 may then transmit the UART compatible serial datapacket containing the attribute values to the host controller 502. TheUART 526 can receive the UART compatible serial data packet and convertthe data into host controller serial data packets, readable by the hostcontroller. In one embodiment, the UART 526 can perform the conversion.In other embodiments, the API 531 can convert the UART compatible serialdata packet into a host controller serial data packet. The hostcontroller serial data packet may then be received by the host interface532. The host interface 532 may then convert the host controller serialdata packet into host device data to be processed by the processingcircuit 550. The host device data may be a proprietary data format usedby the processing circuit 550 of the host controller 502. In otherexamples, the host device data may be a standard data type used by theparticular processing circuit 550.

The processing circuit 550 can then read the host device data via thehost application 556. The host application 556 allows the data to beparsed and executed. In some embodiment, the host application may outputdevice parameters to one or more host device components 570. The hostdevice components may be any components in communication with theprocessing circuit 550. For example, the host device components 570 mayinclude switches, motor controllers, sensors, relays, indicators, or anyother components within the BMS device 503 which is used by the BMSdevice 503 to operate. For example, a host device component 570 may be amotor starter relay. The host application 556, via the processingcircuit 550 may output a logic 1 to the motor starter relay to close,thereby turning on a motor. In a more complex example, the host devicecomponent 570 may be a variable frequency motor controller. In thisexample, the host application 556 via the processing circuit 550 mayoutput a motor speed command. Thus, a command or request may begenerated by the network 504 and/or the controller 506 and executed at acomponent level of the BMS device 503 using the above embodiment.

Turning now to FIG. 5C a block diagram illustrating the flow of datafrom the host controller 502 to the network 504 and/or the controller506 is shown, according to some embodiments. Within the BMS device 503,one or more of the host device components 570 may provide deviceparameters associated with one or more parameters of the host devicecomponent 570 to the processing circuit 550. Device parameters caninclude parameters related to motor speed, temperature, positions, orany other device parameters associated with the host device components570 within the BMS device 503. The device parameters can be processed bythe host application 556 within the processing circuit 550. In someembodiments the processing circuit 550 may determine that the receiveddevice parameters may need to be provided to the network 504 and/or thecontroller 506. For example, the processing circuit 550 may beconfigured to provide all updated parameters to the network 504 and/orthe controller 506. In other examples, the processing circuit 550 may beconfigured to provide device parameters to the network 504 and/or thecontroller 506 when the device parameters exceed a certain value. Instill further examples, the processing circuit 550 may provide thedevice parameters to the network 504 and/or the controller 506 atpredetermined intervals or at predetermined times of the day. Forexample, the processing circuit 550 may be configured to provide thedevice parameters to the network 504 and/or the controller 506 at 6A.M., Noon, 6 P.M. and Midnight. However, the predetermined intervals ortimes may be any predetermined intervals or times provided by a user.Additionally, the processing circuit 550 may be configured to providethe device parameters to the network 504 and/or controller 506 uponreceiving an instruction to do so from the network 504 and/or thecontroller 506. This may be in conjunction with any of the otherconfigurations described above. Further, the processing circuit 550 mayalso provide additional data associated with the processing circuit 550itself, such as alarms, data logs, etc.

The processing circuit 550 may provide host device data containing datarelating to the BMS device 503 (e.g. the processing circuit 550 and/orthe host device components 570) to the host interface 532. The hostinterface 532 may be configured to receive the host device data andconvert the host device data received from the processing circuit intoone or more host controller serial data packets for transmission to thecommunications circuit 500. The host controller serial data packet maythen be provided to the UART 526, which may convert the host controllerserial data packet into a UART compatible serial data packet. In oneembodiment, UART 526 may convert the host controller serial data packetinto the UART compatible serial data packet. Alternatively, the API 531may be used to convert the host controller serial data packet into theUART compatible serial data packet. The UART serial data packet may thenbe transmitted to the UART 524 of the communications circuit 500. TheUART 524 may then convert the UART serial data packet back into the hostcontroller serial data packet. In one embodiment the UART 524 convertsthe UART serial data packet into the host controller serial data packet.In other embodiments, the API 530 converts the UART serial data packetinto the host controller serial data packet.

The host controller serial data packet may then be received by thecommunication task module 522. The communication task module can readthe host controller serial data packet and parse the host controllerserial data packet to extract one or more attribute values. In oneembodiment, the attribute values are values associated with the BMSdevice 503, such as the device parameters of the host device components570, or values associated with the processing circuit. The communicationtask module 522 may then output the attribute values to the respectiveattributes within the equipment object 520. In one embodiment, thecommunication task module 522 may determine which parsed values areassociated with a given attribute of the equipment object by reading anidentifier associated with each portion of the received data, and mapthat to a corresponding attribute within the attribute value. In oneexample, a user can configure the equipment object attributes to relateto data received from the host device by assigning certain dataidentifiers contained within the host controller serial data packet to agiven equipment object attribute. As will be discussed in more detailbelow, the equipment object 520 can be configured using a configurationdevice.

The attribute values stored within the attributes of the equipmentobject 520 can be read by the mapping module 534. The mapping module 534may determine if an attribute value has changed by constantly monitoringthe equipment object 520. In other embodiments, the equipment object 520may provide an interrupt signal to the mapping module 534, indicatingthat an attribute value has been updated. The mapping module 534 maythen read the equipment object attribute data from the equipment object520 and convert the equipment object attribute data in to BACnet objectdata. The mapping module 534 may further be configured to then transmitthe updated BACnet Object Data to the appropriate BACnet object 533. Insome instances, a BACnet object may not current exist that is associatedwith a particular equipment object attribute. The mapping module 534 maythen generate a new BACnet object via the network interface 518. In oneembodiment, the mapping module 534 may already be configured toassociate a given BACnet object 533 with an equipment object 520attribute. In one embodiment, the mapping module 534 may read anattribute ID for each received equipment object attribute data todetermine which BACnet object to map the received data to. In someembodiments, the equipment object 520 may be configured to not exposecertain attributes to the mapping module 534. In those instances, thereceived attribute values are stored in the equipment object 520, butare not provided to the mapping module 534.

Once the BACnet objects 533 receive the BACnet object data, theBACnet/MSTP layer 544 can read the BACnet objects 533 to determine ifany values have been modified. In one embodiment, the BACnet/MSTP layer544 may constantly read all of the BACnet objects 533 to determine ifany values have been changed. In other embodiment, one or more of theBACnet objects 533 may provide an interrupt signal to the BACnet/MSTPlayer 544 to indicate a value has changed. The BACnet/MSTP layer 544 maythen read one or more of the BACnet objects 533 to receive parsed BACnetobject data from the BACnet objects 533. For example, if binary BACnetobject 538 contained updated information, the BACnet/MSTP layer 544 mayrequest and receive data only from the Binary BACnet object 538. TheBACnet/MSTP layer 544 receiving the parsed BACnet object data may thenconvert the parsed BACnet object data into standard BACnet data, andtransmit the BACnet data containing the data from the BMS device 503 tothe network 504. As described above, the BACnet/MSTP layer 544 may, insome examples, only transmit the BACnet data to the network 504 when oneor more external devices are subscribed to receive data from the hostdevice via a BACnet subscription service. In other embodiments, theBACnet/MSTP layer 544 may make the BACnet data available to be read byone or more external devices or systems via the network 504.

Turning now to FIG. 6B, a flow chart illustrating a process 640 forcommunicating data from a BMS device to an external network as describedin FIG. 5B using the system of FIG. 5A, is shown, according to someembodiments. At process block 642, one or more data values may bereceived from the BMS device 503 via the host controller 502. The datavalues may be associated with BMS device 503. The data values may bereceived by the communications circuit 500 via the UART interfaces 524,526. At process block 644, the received data values may be written toone or more attributes within the equipment object 520. In oneembodiment, the communication task module 522 writes the values into theassociated equipment object attributes within the equipment object 520.At process block 646, the one or more equipment object attributes storedwithin the equipment object 520 are mapped to one or more networkobjects. In one embodiment, the network objects are the BACnet objects533 described in FIG. 5A. Further, the equipment object attributes maybe mapped to the one or more network objects by the mapping module 534,as described above in FIG. 5B. Finally, at process block 648, thenetwork objects may be exposed to the network 504. In one embodiment,the BACnet/MSTP layer 544 transmits the network objects to the network504 as described above in FIGS. 5A and 5B where one or more externaldevices have subscribed to the BMS device 503 via a BACnet SubscriptionService.

Turning now to FIG. 6C, a flow chart illustrating a process 660 forcommunicating data from a network to a BMS device as described in FIG.5C using the system of FIG. 5A, is shown, according to some embodiments.At process block 662, one or more data values are received from network504. In one embodiment, the data values are data values to be written tothe BMS device 503. At process block 664, the received data values arewritten into one or more networking objects. In one embodiment, thenetworking objects are the BACnet objects 533 described in FIG. 5A. In afurther embodiment, the received data values are written into the one ormore networking objects by the network/MSTP layer 544, as described inFIGS. 5A and 5C, above. At process block 666, the values written in theone or more networking objects are mapped to one or more equipmentobject attributes within the equipment object 520. In one embodiment,the mapping module 534 maps the values written in the one or morenetworking objects to the one or more equipment object attributes withinthe equipment object 520 as described in FIGS. 5A and 5C, above.Finally, at process block 668, the values written to the one or moreequipment object attributes within the equipment object 520 aretransmitted to the host controller 502 of the BMS device 503. In oneembodiment, the communication task 522 reads and transmits the values inthe equipment object attributes within the equipment object 520 asdescribed in FIGS. 5A and 5C, above. Further, the data values can betransmitted to the host controller 502 via the UART interfaces 524, 526.

Turning now to FIG. 7, a schematic block diagram of the communicationscircuit 500 is shown, according to some embodiments. The communicationscircuit 500 may include a microcontroller unit (MCU) 702, a memory 704,a network transceiver 706, an isolation transformer 708, a voltageregulator 710, protection circuitry 712, and a network connector 714.The communications circuit 500 may optionally include an address switch716, a shift register 718, and an end of line termination switch 720.Similar to above, the communications circuit 500 is in communicationwith the host controller 502. The host controller 502 can be located ina BMS device, as described above. For example, the host controller canbe part of an HVAC device (AHU, RTU, etc.), a sensor (pressure sensor,temperature sensor, etc.), a mechanical device (e.g. valves, actuators,fans, etc.), simple controllers (thermostats, HVAC controllers, etc.),or any other BMS device. The communications circuit 500 is further shownto include one or more indication device 562, as described above. Thecommunications circuit 500 further includes the serial peripheralinterface (SPI) driver 558, which may drive the peripheral port 560, asdescribed above.

The MCU 702 may be a general purpose or specific purpose processor, anapplication specific integrated circuit (ASIC), one or more fieldprogrammable gate arrays (FPGAs), a group of processing components, orother suitable processing components. The MCU 702 is configured toexecute computer code or instructions stored in the memory 704 orreceived from other computer readable media (e.g., CDROM, networkstorage, a remote server, etc.). In one embodiment, the MCU 702 is anRX111 microcontroller from Renesas Electronics America. The MCU 702 canbe configured to communicate with the host MCU 722 via the UARTinterface 524. In some examples, the UART interface 524 may be replacedwith a different type of communication interface, such as an I²Cinterface, an SPI interface, a universal serial bus (USB) interface,etc. As shown in FIG. 7, the UART interface 526 of the host controller502 can be in communication with the UART interface 524 via acommunication line 724. In one example, the communication line 724 mayinclude three communication wires. The three communication wires mayinclude, a first communication wire configured to function as areceiving data wire, a second communication wire configured to be atransmission data wire, and a third communication wire configured to bean external interrupt communication wire. The communication line 724 maybe used to facilitate communication between the MCU 702 and the hostcontroller 502. In other examples, different communication lines may beused as required. In one embodiment, the MCU 702 includes customfirmware related to performing BACnet operations, as described above.Further, the MCU 702 may be in communication with a crystal (not shown)to provide a timing system to the MCU 702. In one embodiment, thecrystal is a 16 MHz crystal. The MCU may also include the deviceinterface 516 and the network interface 518, as described above.

The MCU 702 may be in communication with the memory 704. The memory 704may include one or more devices (e.g., memory units, memory devices,storage devices, etc.) for storing data and/or computer code forcompleting and/or facilitating the various processes described in thepresent disclosure. The memory 704 may include random access memory(RAM), read-only memory (ROM), hard drive storage, temporary storage,non-volatile memory, flash memory, optical memory, or any other suitablememory for storing software objects and/or computer instructions. In oneembodiment, the memory 704 is a serial NOR flash memory. The memory 704may be communicably connected to the MCU 702 via a communication line726. In some embodiments, the memory 704 is integrated in the MCU 702.The memory 704 may include computer code for executing, by the MCU 702,one or more processes described herein. In one embodiment, the memory704 includes software including all data associated with the hostcontroller 502, and/or the BMS device 503. In one embodiment, the memory704 includes eight gigabytes (GB) of storage. However, the memory 704may include more than eight gigabytes or less than eight gigabytes, asrequired by the application. The memory 704 may include software forperforming BACnet operations as described above. Further, the memory 704may include objects, such as equipment objects, and standard BACnetobjects. Further, in some examples the memory 704 can include softwarefor performing alarming, trending, scheduling, etc. These additionalfunctions can be performed by the MCU 702. In one example, thesefunctions may exist solely in the communication circuit 700, therebyallowing for additional functionality to be added to a host device.

In one embodiment, the communications circuit 500 is addressed directlyby a user via software. For example, a user may access the MCU 702 viathe network connector 714 to provide an address for the communicationscircuit 500. In other examples, the user may access the MCU 702 via theperipheral port 560. The peripheral port 560 may provide for connectionto a serial flash device, such as a USB device, an SD or micro SDdevice, a compact flash (CF) device, etc. In still further embodiments,the host controller 502 is used to address the communication circuit500, such as via UART interfaces 524, 526. In other embodiments, thecommunications circuit 500 may include a switch, such as optionaladdress switch 716 to allow a user to manually address the communicationcircuit. In one embodiment, the address switch 716 includes one or moreDIP switches. Alternatively, the address switch 716 may include one ormore rotary switches. In one embodiment, the shift register 718 is usedto translate the address set on the address switch 716 into serializeddata readable by the MCU 702. In some examples, the MCU 702 may beconfigured by a user to prioritize addressing methods. For example, auser may be able to set a flag within the MCU 702 to indicate thataddressing of the communication circuit via the communication interface724 is prioritized over addressing performed using the address switch716, or vice versa.

Turning briefly to FIG. 13, a process 1300 for addressing thecommunication circuit 500 is shown, according to some embodiments. Atprocess block 1302, a flag can be set in the communications circuit 500to establish which type of addressing has priority for thecommunications circuit 500. Example addressing types, as describedabove, may include via the communications circuit 500 itself (e.g. viaaddress switches), or via an external addressing source. Externaladdressing sources may include the network 504, the host controller 502,and/or an external device coupled to the peripheral port 560.Furthermore, the flag may be set via the network 504, via the hostcontroller 502, or via a device coupled to the peripheral port 560.Additionally, in some embodiments, the priority can be a defaultpriority programmed into the communications circuit 500. At processblock 1304, the address may be set for the communications circuit 500using one of the above methods. For example, a user may address thecommunications circuit 500 using the address switch 716 described inFIG. 7. Finally, at process block 1306, the communications circuit 500may execute the addressing command set in process block 1304, based onthe set priority flag. For example, if the address switch 716 providesone address for the communications circuit 500, and a second address isprovided via an external source (e.g. via the network 504, hostcontroller 502, or peripheral port 560), the communications circuit 500may set the address based on which method of addressing is givenpriority. Thus, if the flag is set to give priority to external sourceaddressing, the communications circuit 500 (e.g. via MCU 702) mayoverride an address entered via the address switch 716, and set theaddress provided by the external source.

In one embodiment, the network transceiver 706 is an RS-485 transceiver.In a further embodiment, the network transceiver 706 is an RS-485transceiver for communicating over a BACnet network. In one example, thenetwork transceiver 706 may be an ISO1176 transceiver from TexasInstruments. The network transceiver 706 may be electrically isolatedfrom the MCU 702 and the host controller 502. For example, the networktransceiver 706 may be located on an isolated plane 732. The isolatedplane 732 can reduce the effects of ground loops and noise from the MCU702. In one embodiment, by positioning the network transceiver 706 onthe isolated plane 732, the number of communication devices that canshare a common RS-485 bus can be increased due to the reduction ofinterference from the MCU 702 and/or the host controller 502. Theisolation transformer 708 and regulator 710 can further be located onthe isolated plane 728 and provide additional isolation for the networktransceiver 706. In one embodiment, the isolation transformer 708 andregulator 710 can provide an isolated power supply to the networktransceiver 706, by isolating and regulating a power supply 734 providedto the communication circuit 700. The network connector 714 may furtherbe located on the isolated plane 728. In one embodiment, the networkconnector 714 is a four-pin connector from Phoenix Contact. The networkconnector 714 may provide a connection to a BACnet network backbone ortrunk line. In one embodiment, the network connector 714 may provide aconnection to an additional BACnet interface device, such as a wirelesscommunication device, such as Wi-Fi, LoRA RF, Zigbee, Bluetooth,cellular (3G, 4G, LTE, CDMA, etc.) or other applicable wirelesscommunication devices. Where the communications circuit 500 is the lastdevice on a network (e.g. a BACnet network), the end of line (EOL)termination switch 720 can provide the proper termination for thenetwork.

The power supply 734 can be a 3.3 VDC power supply supplied from anexternal source. In one embodiment, the power supply 734 is supplied bya host device, such as BMS device 503. In a further embodiment, thepower supply 734 provides a 100 mA service to the communications circuit500. However, the power supply 734 can provide more than a 100 mAservice or less than a 100 mA service, as applicable.

As described above in FIG. 7, as well as in FIG. 5, the MCU 702communicates with the host controller via a serial interface overcommunication line 724. The communications circuit 500 can supportmultiple standard serial interfaces as described above (e.g. UART, SPI,I²C, USB, etc.). While multiple types of serial interfaces can be used,the messages transmitted across any of the serial interfaces stay thesame. For example, regardless of the interface, the exchange between thehost controller 502 and the MCU 702 will consist of the host controller502 sending a request message and the MCU 702 sending a reply message.

In some embodiments, when the communications circuit 500 is initiallypowered up or restarted, the communications circuit 500 may require thehost controller 502 to execute a startup sequence. The startup sequencemay be designed to allow both the communications circuit 500 and thehost controller 502 to synchronize data between them. In one embodiment,the host controller 502 is responsible for initiating the startupsequence. However, in some examples the communications circuit 500 mayinitiate the startup sequence. Turning now to FIG. 8, a sequence diagramshowing an example startup sequence 800 is shown, according to someembodiments. The startup sequence 800 is shown to have the hostcontroller 502 initiate the startup sequence 800 with the communicationscircuit 500. At the startup command call state 806, the host controller502 may continuously send a startup command until the host controllerreceives an “OK” reply status from the communications circuit 500. Wherethe host controller 502 receives a “wait” reply status form thecommunication circuit, or no reply status at all, the host controller502 may continuously repeat the startup command. In some embodiments,the host controller 502 will continuously send the startup command tothe communications circuit 500 until a predetermined amount of timeexpires. For example, the predetermined time may be five seconds.However, the predetermined time may be more than five seconds or lessthan five seconds. Further, the host controller 502 may be configured tocontinuously send the startup command to the communications circuit 500for a predetermined number of attempts. For example, the predeterminednumber of attempts may be twenty. However, more than twenty attempts orless than twenty attempts are contemplated predetermined values as well.

Upon receiving the “OK” status, host controller 502 may then send anumber of values to the communications circuit 500 during the UpdateValue Command Call state 808. The values can represent attributes of anequipment object, as described above. In one embodiment, thecommunications circuit 500 responds to each update value command with an“OK” reply status. Once the host controller 502 has sent all of theupdated values, the host controller 502 may then transmit an “UpdateDone” command to the communications circuit 500 during the Update DoneCommand Call state 810. In one embodiment, the communications circuit500 can begin initiating communication with an external network once theUpdate Done command has been received. For example, the communicationscircuit 500 may initiate communication with a BACnet network once theUpdate Done command has been received. At Status command call 812, thecommunications circuit 500 can send a reply status OK, indicatingcommunication with the external network is operating correctly. Wherethe communication between the communications circuit 500 and theexternal network fails, the communications circuit 500 may send a“comm_failed” reply status to the host controller 502.

In some examples, the host controller 502 may perform the startupsequence 800 more than once. Where the host controller 502 initiates thestartup sequence 800 more than once, the communications circuit 500performs the startup sequence 800 as described above, except that itwill only initialize the communications with the external network forthe first startup sequence request from the host controller 502, unlessthe communication with the external network failed during the firstattempt. Once the communication between the communications circuit 500and the external network has been initiated, the communications circuit500 will send an “OK” reply command to the host controller 502 inresponse to the “Update Done” command for each subsequent startupsequence 800 request. Further, where the startup sequence 800 is notinitiated after a restart of the communications circuit 500, thecommunications circuit 500 will reply to all requests by the hostcontroller 502 with an error message indicating that the communicationscircuit 500 has been restarted and is awaiting the startup sequence 800.

As described in FIGS. 5A-5C, a host controller and a communicationcircuit may perform data exchanges, which will be described in moredetail below. These data exchanges utilize data packets to perform thedata transfers. Each data packet may use multiple data units of varyingsizes. Example data units are illustrated in Table 1, below.

TABLE 1 Data Unit Definitions Data Unit Name Number of Bits UCHAR  8USHORT 16 ULONG 32 FLOAT32 32 Variable Any (in 8 bit increments)

The order of the bytes for any of the above data units may follow one ormore conventional formats. In one embodiment, the above data typesfollow the Big Endian format, wherein the most significant byte of avalue is transmitted first. As shown above, the FLOAT32 data unit can beformatted according to ANSI/IEEE standard 754-1985 “IEEE Standard forBinary Floating-Point Arithmetic.”

Table 2, shown below, depicts an exemplary packet structure which may beused in communication between a communication device and a host device,as described above.

TABLE 2 Basic Packet Structure SoT LENGTH CMD DATA CRC EoT UCHAR USHORTUCHAR VARIABLE USHORT UCHAR

As shown in Table 2, the basic packet structure begins with a Start ofTransmission (SoT) character. The SoT character may be defined as astandard 8-bit data character. For example, the SoT character can bedefined as a value 0x72h. Similarly, the End of Transmission (EoT)character, which is the last character within the data packet, may bedefined as a standard 8-bit data character as well. For example, the EoTcharacter may be defined as a value of 0x73h. The purpose of the SoTcharacter and the EoT character is to allow the receiving device (e.g. acommunication circuit or a host device) to detect that a full lengthmessage has been sent or received. The SoT character within the packetstructure is followed by the LENGTH character. The LENGTH character isdefined as a USHORT data type. The LENGTH character is defined as thesize of the CMD character and the DATA character, combined. In oneembodiment, the LENGTH character can define the size of the combinationof the CMD character and the DATA character in the number of Octets.Alternatively, the LENGTH character can define the size of thecombination of the CMD character and the DATA character in the number ofbytes. The CMD character represents commands that either the host deviceor the communication device exchange for a given action. The DATA fieldis only present in certain commands and may vary in size depending onthe specific command provided in the CMD character. A cyclic redundancycheck (CRC) character then follows the DATA field. The CRC character canbe a standard CRC polynomial used as an error-detecting code. Forexample, the CRC polynomial can be x16+12+x5+1. As stated above, the EoTcharacter ends the basic data packet. The data packet structure may havea minimum and maximum size. In one embodiment, the minimum size is sevenOctets and the maximum size is eighteen Octets. However minimum sizesgreater than seven Octets or less than seven Octets, and maximum sizesgreater than eighteen Octets or less than eighteen Octets arecontemplated.

Table 3, below, shows example command codes that may be issued between ahost device and a communication circuit, such as those described above.Table 3 further shows possible replies to the given commands. As statedabove, each command instructs the receiving device (i.e. the host deviceor the communication circuit) to execute one or more routines. In oneembodiment, the command codes are incorporated within the CMD characterof the basic packet structure, described above in Table 2.

TABLE 3 Exemplary List of Commands Communication Host Circuit (CC)Device Reply Command Command DESCRIPTION OP CODE START UP The commandsent by host device to CC 0x01 which allows CC to initialize and signalto the host device when ready for normal communication. REPLY Simplecommand to return Status. 0x06 STATUS Possible Status returned to STARTUP are OK, WAIT, CRC_ERROR. UPDATE The periodic command sent from thehost 0x02 HOST device to the CC requesting if any attribute has changed.Two possible replies from CC. UPDATE A reply command from the CC to thehost 0x03 HOST REPLY device UPDATE HOST request, giving the attributenumber that has changed. If nothing has changed a Reply Status is sentinstead. The host device will then read the value of the attributespecified in this command. REPLY Simple command to return Status. 0x06STATUS Possible Status values OK, CC_NOT_STARTED, CRC_ERROR UPDATE Acommand issued by the host device for 0x04 VALUE it to send a new valuefor the specified attribute. REPLY Possible Status values OK, 0x06STATUS CC_NOT_STARTED, ATTRIBUTE_ID_NOT_FOUND, INVALID_ENUM_VALUE,CRC_ERROR READ The command issued by the host device to 0x05 VALUE readan attribute value from the CC. The value read will be typically be thevalue returned in the UPDATE HOST REPLY command. UPDATE The commandissued by JBOC to reply 0x04 VALUE with the requested value. REPLYPossible Status values 0x06 STATUS CC_NOT_STARTED,ATTRIBUTE_ID_NOT_FOUND, CRC_ERROR RESTART The command from the HOST torestart 0x07 JBOC the CC. After restarting CC will wait for the START UPcommand REPLY Possible Status values OK, CRC_ERROR 0x06 STATUS UPDATEThe command from the host device to the 0x08 DONE CC. Host device isdone sending all his initial updates REPLY Possible Status values OK,0x06 STATUS JBOC_NOT_STARTED, CRC_ERROR

Table 4, below, provides an exemplary list of status codes that canaccompany a Reply Status command.

TABLE 4 Error Codes Reply Status Code Description OP Code OK Everythingis OK 0x01 WAIT Busy 0x02 CC_NOT_STARTED Communication Circuit is yet tostart, 0x03 host device should initiate startup sequenceATTRIBUTE_ID_NOT_FOUND Communication Circuit could not find 0x04attribute value requested in the Read request CRC ERROR CRC validationfailed 0x05 BAC_COMM_FAILED Failed to initialize the BACCOM 0x06interface INVALID_ENUM_VALUE An enumeration value was sent by the 0x08host in the Update Value command that is too large for the set defined.

In one embodiment, communication and data transfers (such as thosedescribed above) are initiated only by a host controller. The associatedcommunication circuit therefore will only respond to a request from thehost controller. However, in other examples, the communication circuitmay initiate communication with the host controller. Further, standardtiming requirements may be used to ensure proper communication between acommunication circuit and the host controller. In one embodiment, themaximum delay between characters of a message being transmitted by ahost controller or a communication device is fifty milliseconds.However, maximum delays of more than fifty milliseconds or less thanfifty milliseconds are considered. In some embodiments, the host devicewill wait for a predetermined time period for a response from acommunication circuit after transmitting a message/request. In oneembodiment, the predetermined time period is two seconds. However,predetermined time periods of more than two seconds or less than twoseconds are also considered. The host controller, not receiving aresponse from the communication circuit by the expiration of thepredetermined time may cancel the original request and resubmit themessage/request to the communication circuit.

In some embodiments, a communication circuit, such as those described inFIGS. 5A-5C, may be configured to persist value, such that the valuescan be modified via an external network for the host controller. In oneexample, the external network is a BACnet network. Generally, a hostcontroller may already persist those values identified as being able tobe modified via an external network, so the communication circuit isconfigured to not persist the values that can be written via theexternal network. Where the host controller persists the values, thehost controller is the source of all persisted values, and must synchthe persisted values when the host controller is initialized. If thecommunication circuit is configured to persist the written values, thecommunication circuit must flag all of the values that are persisted ashaving changed during a startup process, and send the changed persistedvalues to the host controller.

Turning now to FIG. 9, a data transfer process 900 for transferring databetween a communications circuit 500 and a host controller 502 is shown,according to some embodiments. In one embodiment, the data transferprocess 900 is used to write data received by the communications circuit500 from an external network. For example, the external network may be aBACnet network. However, other external networks are contemplated. Inone embodiment, the data transfer process can be initiated after thestartup sequence 800 described in FIG. 8 has been completed.

In one embodiment, the host controller 502 periodically initiates an“Update_Host” command 906 to be sent to the communications circuit 500.The Update_Host command 906 can be used to request any updatedattributes within the communications circuit 500 be communicated to thehost controller 502. In one embodiment, the updated attributes can beupdated attributes within an equipment object of the communicationscircuit 500. In other examples, the updated attributes can be attributesof other data objects, such as the standard BACnet objects discussedabove. The communications circuit 500 may reply to the host controller502 with either an “Update_Host_Reply” command 908 or a “Reply_Status”command 910, which are described in more detail below. In one example,the Update_Host command 906 may act as a heartbeat signal due to itsperiodic initiation.

The Update_Host_Reply command 908 can be transmitted to the hostcontroller 502 along with one or more attributes that have changed. Inone embodiment, the Update_Host_Reply command 908 includes an attributeID of the attribute that has changed. The host device 904, receiving anUpdate_Host_Reply command 908 with a changed attribute may respond witha “Read_Value” command 912 to the communications circuit 500 to requestthe new attribute data. In response, the communications circuit 500 mayrespond to the Read_Value command 912 with either an “Update_Value”command 914 containing the new data value for the attribute, or theReply_Status command 910. In one embodiment, the Reply_Status command910 is transmitted to the host controller 502 from the communicationscircuit 500 where the changed attribute value is unable to be providedto the host controller 502. The Reply_Status command 910, in response tothe Read_Value command 912 may reply with one or more status values. Inone example, the status value can be a CRC ERROR value. The CRC ERRORvalue can indicate that there was a problem with the Read_Value command912, and instruct the host controller 502 to repeat the Read_Valuecommand 912. Other example status values returned in the Reply_Statuscommand 910 can include an “Attribute_ID_Not_Found” value. TheAttribute_ID_Not_Found value may signal to the host controller 502 thatthere is a software problem preventing the host controller 502 frombeing read. In one embodiment, if the host controller 502 does not issuethe Read_Value command 912, the communications circuit 500 will resendthe Update_Host_Reply 908 containing the unread attribute value inresponse to a subsequent Update_Host command 906. In a furtherembodiment, the host controller 502 will continue to transmit theRead_Value command 912 to the communications circuit 500 to request aread of the specified attribute. For example, the host controller 502may re-transmit the Read_Value command 912 if a response is not receivedfrom the communications circuit 500 after a pre-determined time. In oneembodiment, the predetermined time is two seconds. However,predetermined times of more than two seconds or less than two secondsare also considered. In one embodiment, the communications circuit 500will not send any data again to the host controller 502 until it isrequested again by the host controller 502.

Where the communications circuit 500 replies to the Update_Host command906 with the Reply_Status command 910, the Reply_Status command 910 mayinclude one or more status values within the command. For example, theReply_Status command 910 may include one or more of the reply statusmessages listed in Table 4, above.

Turning now to FIG. 10, a host to communication circuit update process1000 is shown, according to some embodiments. A host controller 502 mayrequire an updated value from a communications circuit 500, as shown inFIG. 10. The host controller 502 may send an “UPDATE_VALUE” command 1006to send the new value to the communications circuit 500. In reply to theUPDATE_VALUE command 1006, the communications circuit 500 may return aREPLY_STATUS command 1008. The REPLY_STATUS command 1008 can includereply status messages, such as those listed in Table 4, above.

Turning now to FIG. 11, a communication circuit restart process 1100 isshown, according to some embodiments. The communication circuit restartprocess 1100 may be initiated by a host controller 502 and processed bya communications circuit 500. In one embodiment, the process 1100 isinitiated when the host controller 502 is restarting itself.Alternatively, the process 1100 can be initiated when an error in thecommunication between the host controller 502 and the communicationscircuit 500 is detected. The host controller 502 may shut off acommunication interface to the communications circuit 500 prior torestarting. In one embodiment, the host controller 502 issues a “RESTARTCC” command 1106 to the communications circuit 500. The communicationscircuit 500 may respond with a REPLY_STATUS command 1108 including areply status message, such as those listed in Table 4, above. Where thecommunications circuit 500 responds with an “OK” reply status message,the communications circuit 500 has received the command, and willrestart after a predetermined delay. In one embodiment, thepredetermined delay is five seconds. However, predetermined delays ofmore than five seconds, or less than five seconds are contemplated.

Turning now to FIG. 12, a static data communication process 1200 isshown, according to some embodiments. The static data communicationprocess 1200 may be initiated by the host controller 502, and processedby the communications circuit 500. In one embodiment, the process 1200is initiated when the host controller 502 transmits data to thecommunication controller that is static or “not real” data. Example,static data may include data packets transmitted by the host controllerthat do not include any data related to the host controller 502, such asvarious headers, status checks, heartbeats, etc., which are used by thenative host controller 502 applications, but are not desired orinterpretable by the communication circuit 500. In one embodiment, thehost controller 502 is configured to transmit a “Static_Data_Signal”1202 to the communication circuit to indicate that static data is aboutto be transmitted. In alternate embodiments, the Static_Data_Signal 1202can be sent after the static data has been transmitted to thecommunications circuit 500. The Static_Data_Signal 1202 may beinterpreted by the communications circuit 500 to ensure that thecommunications circuit 500 does not try to process the static data,which could result in an error being generated. In some embodiments, theStatic_Data_Signal 1202 may include information, such as the durationand/or length of the static data being transmitted by the hostcontroller 502. The communications circuit 500, receiving theStatic_Data_Signal 1202 may respond with a REPLY_STATUS command 1204including a reply status message, such as those listed in Table 4,above. In still further embodiments, the Static_Data_Signal 1202 may beone or more data headers that can be interpreted by the communicationtask module 522 as indicating static data. The communication task module522 may then prohibit any data following the interpretedStatic_Data_Signal 1202 from being written into the equipment objectmodel. The communication task module 522 may continue to prohibit datareceived from the host controller 502 from being written to thecommunication circuit 500 until a subsequent signal indicating actualdata is received, such as those described in Tables 2-4, and FIGS. 8-11,described above. Where the Static_Data_Signal 1202 is comprised of oneor more data headers that can be interpreted by the communication taskmodule 522 as indicating static data, the communication circuit 500 maynot provide a REPLY_Status command 1204. However, in some embodiments,the REPLY_STATUS command 1204 may be provided to the host controller 502to indicate that the transmitted data was received by the communicationscircuit 500.

In some embodiments the host controller 502 may execute a static datadetermination process 1206 as shown in FIG. 12. The host controller 502may first read the data at process block 1208 that is being transmittedto the communications circuit to determine what the data is associatedwith. The host controller 502 may then determine if the data is staticdata at process block 1210. If the data is determined to be static data,the Static_Data_Signal 1202 may be transmitted to the communicationcircuit 500 at process block 1212. Where the host controller 502determines that the data is not static data, the data is transmitted tothe communication circuit at process block 1214, allowing thecommunication circuit 500 to expose the associated attribute in theequipment object 520 to the BACnet objects 533. In some embodiments, theprocess 1206 is performed for all data points during initial setup toprevent unnecessary static data from being provided to a user via theBACnet objects 533.

The following non-limiting examples described possible determinations ofstatic data that may be performed by the host controller 502. In thefirst example, the BMS device 503 may have a one or more optionalsensors that may be coupled to the BMS device 503. Where the optionalsensors are not present on the BMS device 503, an error message, and/ora default value associated with the sensor inputs (e.g. a default datapoint, or binary state) may constantly be provided to the hostcontroller 502. The host controller 502, determining that the optionalsensors have never been installed on the BMS device 503, may thendetermine that the data associated with the optional sensors is staticdata, and transmit the Static_Data_Signal 1202 to the communicationcircuit 500 to prevent the static data from being exposed to the BACnetobjects.

In a further example, a setting may exist on the BMS device 503. Whenthe setting is activated, additional data, (e.g., two additional datapoints) may be required to be provided with the setting. Thus, when thesetting is activated, the additional data points are not static data,and may be provided to the communication circuit 500 by the host device502 for exposure to the BACnet objects 533. However, where the settingis not activated, the data is not required, and therefore static.Accordingly, the host controller 502 can determine that the data isstatic when the setting is not activated and provide aStatic_Data_Signal 1202 associated with the additional data points, sothat the data points are not exposed to the BACnet objects. In a stillfurther example, the BMS device 503 may be a system, such as an RTU. Insome instances, portions of the system may not be active, or eveninstalled, based on the specific configuration needed for anapplication. Thus, the host controller 502 may determine that all of thedata associated with the inactive, or uninstalled, portions of thesystem are static, and provide the Static_Data_Signal 1202 along withall data associated with the inactive and/or uninstalled portions of thesystem. The above examples are for illustrative purposes only, andshould not be construed as limiting.

Example Implementation—Actuator

Turning now to FIG. 14, an actuator 1400 for use in an HVAC systems isshown, according to some embodiments. In some implementations, actuator1400 can be used in an HVAC system 100, waterside system 200, airsidesystem 300, or BMS 400, as described with reference to FIGS. 1-4. Forexample, actuator 1400 may be a damper actuator, a valve actuator, a fanactuator, a pump actuator, or any other type of actuator that can beused in an HVAC system or BMS. In various embodiments, actuator 1400 canbe a linear actuator, or a non-spring return actuator.

Actuator 1400 is shown to include a housing 1402 having a front side1404 (i.e. side A), a rear side 1406 (i.e. side B) opposite front side1404, and a bottom 1408. The housing 1402 may contain the mechanical andprocessing components of actuator 1400. In one embodiment, the housing1402 contains a host controller and a communication circuit, such asthose described above in regard to at least FIG. 5A. In furtherembodiments, the housing 1402 contains a brushless direct current (BLDC)motor and a processing circuit configured to provide a pulse widthmodulated (PWM) DC output to control the speed of the BLDC motor. Theprocessing circuit can be configured to compare a representation of theelectric current output to the BLDC motor to a threshold and may holdthe PWM DC output in an off state when the current exceeds thethreshold. The processing circuit may also be configured to set the PWMDC output to zero and then ramp up the PWM DC output when actuator 1400approaches an end stop.

The actuator 1400 is shown to include a drive device 1410. The drivedevice 1410 can be a drive mechanism, a hub, or other device configuredto drive or effectuate movement of an HVAC system component. Forexample, the drive device 1410 can be configured to receive a shaft of adamper, a valve, or any other movable HVAC system component in order todrive (e.g., rotate) the shaft. In some embodiments, the actuator 1400includes a coupling device 1412 configured to aid in coupling the drivedevice 1410 to the movable HVAC system component. For example, thecoupling device 1412 may facilitate attaching the drive device 1410 to avalve or damper shaft.

The actuator 1400 is shown to include an input connection 1416 and anoutput connection 1418. In some embodiments, the input connection 1416and the output connection 1418 are located along the bottom 1408 of theactuator 1400. In other embodiments, the input connection 1416 and theoutput connection 1418 can be located along one or more other surfacesof housing 1402. The input connection 1416 can be configured to receivea control signal (e.g., a voltage input signal) from an external systemor device. The actuator 1400 may use the control signal to determine anappropriate PWM DC output for the BLDC motor. In some embodiments, thecontrol signal is received from a controller such as an AHU controller(e.g., AHU controller 330), an economizer controller, a supervisorycontroller (e.g., BMS controller 366), a zone controller, a fieldcontroller, an enterprise level controller, a motor controller, anequipment-level controller (e.g., an actuator controller) or any othertype of controller that can be used in a HVAC system or BMS.

In some embodiments, the control signal is a DC voltage signal. Theactuator 1400 can be a linear proportional actuator configured tocontrol the position of the drive device 1410 according to the value ofthe DC voltage received at input connection 1416. For example, a minimuminput voltage (e.g., 0.0 VDC) may correspond to a minimum rotationalposition of drive device 1410 (e.g., 0 degrees, −5 degrees, etc.),whereas a maximum input voltage (e.g., 10.0 VDC) may correspond to amaximum rotational position of the drive device 1410 (e.g., 90 degrees,95 degrees, etc.). Input voltages between the minimum and maximum inputvoltages may cause the actuator 1400 to move the drive device 1410 intoan intermediate position between the minimum rotational position and themaximum rotational position. In other embodiments, the actuator 1400 canbe a non-linear actuator or may use different input voltage ranges or adifferent type of input signal (e.g., AC voltage or current) to controlthe position and/or rotational speed of the drive device 1410.

In some embodiments, the control signal is an AC voltage signal. Theinput connection 1416 can be configured to receive an AC voltage signalhaving a standard power line voltage (e.g., 120 VAC or 230 VAC at 50/60Hz). The frequency of the voltage signal can be modulated (e.g., by acontroller for actuator 1400) to adjust the rotational position and/orspeed of the drive device 1410. In some embodiments, the actuator 1400uses the voltage signal to power various components of actuator 1400.The actuator 1400 may use the AC voltage signal received via the inputconnection 1416 as a control signal, a source of electric power, orboth. In some embodiments, the voltage signal is received at the inputconnection 1416 from a power supply line that provides the actuator 1400with an AC voltage having a constant or substantially constant frequency(e.g., 120 VAC or 230 VAC at 50 Hz or 60 Hz). The input connection 1420may include one or more data connections (separate from the power supplyline) through which the actuator 1400 receives control signals from acontroller or another actuator (e.g., 0-10 VDC control signals).

In some embodiments, the control signal is received at the inputconnection 1416 from another actuator. For example, if multipleactuators are interconnected in a tandem arrangement, the inputconnection 1416 can be connected (e.g., via a communications bus) to theoutput data connection of another actuator. One of the actuators can bearranged as a master actuator with its input connection 1416 connectedto a controller, whereas the other actuators can be arranged as slaveactuators with their respective input connections connected to theoutput connection 1418 of the master actuator.

The output connection 1418 can be configured to provide a feedbacksignal to a controller of the HVAC system or BMS, in which the actuator1400 is implemented (e.g., an AHU controller, an economizer controller,a supervisory controller, a zone controller, a field controller, anenterprise level controller, etc.). The feedback signal may indicate therotational position and/or speed of actuator 1400. In some embodiments,the output connection 1418 can be configured to provide a control signalto another actuator (e.g., a slave actuator) arranged in tandem with theactuator 1400. The input connection 1416 and the output connection 1418can be connected to the controller or the other actuator via acommunications bus.

In some embodiments, the input connection 1416 and the output connection1418 can be replaced or supplemented by a communications circuit, suchas communications circuit 500 described above in FIG. 5A. Thecommunications circuit 500 may be configured to support a variety ofdata communications between the actuator 1400 and external systems ordevices. Turning now to FIG. 15, a block diagram illustrating thecommunications circuit 500 for use with the actuator 1400 is shown,according to some embodiments. More specifically, the communicationscircuit 500 is used to support a variety of data communication between acontroller 1502 of the actuator 1400, and one or more external systemsor device. As described above, the communications circuit 500 can be awired or wireless communications link and may use any of a variety ofdisparate communications protocols (e.g., BACnet, LON, WiFi, Bluetooth,NFC, TCP/IP, etc.). In some embodiments, the communications circuit 500is an integrated circuit, chip, or microcontroller unit (MCU) configuredto bridge communications between the actuator 1400 and external systemsor devices. As shown in FIG. 15, the communications circuit 500 is shownas integrated with the actuator 1400. However, in some embodiments, thecommunications circuit 500 may be a separate device from the actuator1400.

As described above, the communications circuit 500 can be configured tosupport a variety of data communications between the controller 1502 ofthe actuator 1400 and external systems or devices (e.g., the network504, the controller 506, one or more enterprise control applications508, one or more client devices 510, one or more remote systems and/orapplications 512, and/or one or more monitoring and reportingapplications 514). The communication link 546 of the communicationscircuit 500 can be a wired or wireless communications link and may useany of a variety of disparate communications protocols as describedabove (e.g., BACnet, LON, WiFi, Bluetooth, NFC, TCP/IP, etc.). In someembodiments, the communications circuit 500 is an integrated circuit,chip, or microcontroller unit (MCU) separate from a processing circuit1504 of the actuator 1400 and configured to bridge communicationsbetween the controller 1502 and the one or more external systems ordevices described above.

In some embodiments, the communications circuit 500 is the JohnsonControls BACnet on a Chip (JBOC) product, as described above. Forexample, the communications circuit 500 can be a pre-certified BACnetcommunication circuit capable of communicating on a building automationand controls network (BACnet) using a master/slave token passing (MSTP)protocol. In other words, the communications circuit 500 provides anetwork interface 518 for the actuator 1400.

As described above, the communications circuit 500 includes a deviceinterface 516 and a network interface 518. In one embodiment, thenetwork interface 518 is a BACnet interface for providing a BACnetinterface for the actuator 1400. The device interface 516 is shown toinclude an equipment object 520, a communications task module 522 (e.g.,a JBOC task), and a universal asynchronous receiver/transmitter (UART)interface 524. The UART interface 524 may be configured to communicatewith a corresponding UART interface 1506 of the actuator controller 1502using a UART protocol. In other embodiments, UART interfaces 524, 1506can be replaced with serial peripheral interfaces (SPI) orinter-integrated circuit (I2C) interfaces.

The communication task module 522 can be connected to the UART interface524 via an application-program interface (API) 530 and can be configuredto populate equipment object 520 with values received from theprocessing circuit 1504 via the UART interfaces 524, 1506. Thecommunication task module 522 can also read values of the equipmentobject 520 set by the network interface 518, and can provide the valuesto processing circuit 1504. Similarly, the UART interface 1506 can beconnected to a host interface 1508 via an API 1510 and can be configuredto communicate with a host application 1512 within the processingcircuit 1504.

The processing circuit 1504 may include a processor 1514 and a memory1516. The processor 1514 may be a general purpose or specific purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable processing components. The processor 1514is configured to execute computer code or instructions stored in thememory 1516 or received from other computer readable media (e.g., CDROM,network storage, a remote server, etc.).

The memory 1516 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 1516 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 1516 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 1516 may becommunicably connected to the processor 1514 via the processing circuit1504 and may include computer code for executing (e.g., by theprocessor) one or more processes described herein. When the processor1514 executes instructions stored in the memory 1516, the processor 1514generally configures the actuator controller 1502 (and more particularlythe processing circuit 1504) to complete such activities.

In one embodiment, the memory 1516 stores the host application 1512. Thehost application 1512 can include the required application for operatingthe actuator 1400. In one embodiment, the host application 1512 cangenerate updated values for the attributes of the equipment object 520,which can be communicated to the device interface 516 via the UARTinterfaces 524, 1506, as described above. The host application 1512 caninclude software to read and store data received by the actuatorcontroller 1502. For example, the actuator controller 1502 may includesensors for detecting various attributes of the actuator 1400. Examplesensors can include a motor current sensor 1518, one or more positionsensors 1520, as well as other sensors such as temperature sensors,voltage sensors, etc. The host application 1512 may read the data via anactuator controller interface 1522, and subsequently store the data fromthese sensors within the memory 1516. Further, the host controller 1502may include other data such as setpoints, position commands, diagnosticdata, etc., which the host application 1512 can further read and storein the memory 1516. In a further embodiment, the host application 1512can control the actuator 1400 by outputting values to the individualcomponents of the actuator 1400. For example, the host application 1512can send a command signal to a motor drive inverter 1524 via theactuator controller interface 1522. In one embodiment, the commandsignal provides a direction to command a brushless DC motor 1526. Thebrushless DC motor can then drive a drive device 1528, as describedabove, which in turn actuates one or more pieces of equipment 1530. Inone example, the equipment 1530 may be a valve. In some embodiments, theposition sensor 1520 can determine a position of the drive device 1528and provide the position information to the host application 1512 viathe actuator controller interface 1522. In some embodiments, theposition sensor 1520 may detect a position of the equipment 1530, andprovide the position information to the host application 1512 via theactuator controller interface 1522.

The host application 1512 can further receive data and/or commands forcontrolling the actuator controller 1502. In one embodiment, the hostinterface 1508 may receive data via the UART interface 1506, andcommunicate the data to the host application 1512. For example, theactuator controller 1502 may communicate with the communications circuit500 and change a setpoint within the analog value BACnet object 540. Thenetwork interface 518 can then modify the corresponding attribute in theequipment object 520, which can then be communicated to the host devicevia the UART interfaces 524, 1506. The host interface 1508 can thenreceive the data via the host API 1510. The host interface 1508 may beconfigured to convert the received data (e.g. the setpoint change) intoa format compatible with the host application 1512. The host application1512, receiving the data (setpoint change) can then implement thesetpoint change on the actuator controller 1502. In one embodiment, thehost application 1512 can control components of the actuator 1400, suchas the motor drive inverter 1524, via the actuator controller interface1522. In some embodiments, the host application 1512 may receive inputsor commands directly from a user interface (not shown) of the actuatorcontroller 1502. The host application 1512 can then update any changesprovided via the user interface in the equipment object 520 bycommunicating the changes to the host interface 1508. The host interface1508 may then communicate the changes to the equipment object 520 viathe UART interfaces 524, 1506.

As described above, the equipment object 520 can be a proprietaryequipment object configured to expose internal actuator data 1532 to thenetwork interface 518. Attributes of equipment object 520 can be definedby a user (e.g., using a data definition tool) to expose any type ofinternal actuator data 1532 to the network interface 518. For example,attributes of equipment object 520 can include the sensed motor current,end stop locations, actuator status, stroke length, actuator position,setpoints, and/or any other type of variable or parameter used or storedinternally by actuator 1400.

The host application 1512 can generate updated values for the attributesof the equipment object 520, which can be communicated to the deviceinterface 516 via the UART interfaces 524, 1506. The attributes of theequipment object 520 can be read by the network interface 518 andcommunicated to the actuator controller 1502 as standard BACnet objects533. As described above, the BACnet objects may include the file object535, the device object 536, the analog value object 540, the binaryvalue object 538, and the multistate value object 542. The BACnetobjects 533 can be mapped to corresponding attributes of the equipmentobject 520 by the mapping module 534 to expose such attributes asstandard BACnet objects, as described above, and further illustrated inFIGS. 16-18, below.

Still referring to FIG. 15, the network interface 518 is shown toinclude the BACnet/MSTP layer 544. The BACnet/MSTP layer 544 can beconfigured to interface with BACnet objects 533 and the externalcommunications network 504 (e.g., a BACnet network). In someembodiments, the BACnet/MSTP layer 544 communicates directly with thecontroller 506. the BACnet/MSTP layer 544 can be configured tofacilitate BACnet communications using the MSTP Master protocol. Forexample, the BACnet/MSTP layer 544 can be configured to transmit andreceive segmented messages and automatically determine a baud rate. TheBACnet/MSTP layer 544 may support duplicate address avoidance by keepinga second device with a duplicate address from interfering with existingtraffic. In other embodiments, the BACnet/MSTP layer 544 may use othertypes of communications protocols such as TCP/IP, Ethernet, WiFi,Zigbee, NFC, etc.

The BACnet/MSTP layer 544 can be configured to read and write values tothe BACnet objects 533. For example, the BACnet/MSTP layer 544 mayreceive a position setpoint from the controller 506 and update aninstance of the analog value object 540 with the position setpoint. Thenetwork interface 1604 can be configured to write the values of BACnetobjects 533 to attributes of equipment object 520, as will be shown inmore detail below. The attribute values of equipment object 520 can becommunicated to the processing circuit 1504 via the UART interfaces 524,1506 and used by the processing circuit 1504 to operate the actuator1500. Similarly, the internal actuator data 1532 generated by theprocessing circuit 1504 can be written to the equipment object 520,mapped to BACnet objects 533, and read by the BACnet/MSTP layer 544. TheBACnet/MSTP layer 544 can send the values of BACnet objects 533 to thecontroller 506, the network 504, the one or more client devices 510, theremote systems and applications 512, the enterprise control applications508, and/or the monitoring and reporting applications 514.

Referring now to FIG. 16, a block diagram illustrating the flow of datafrom the network 504 and/or the controller 506 to the actuatorcontroller 1502 is shown, according to some embodiments. As shown inFIG. 16, network 504 is a BACnet network; however, other networks arecontemplated. The network 504 and/or the controller 506 may provideBACnet data to the communications circuit 500. The BACnet data may bereceived by the BACnet/MSTP layer 544. The BACnet/MSTP layer 544 mayparse the received BACnet data. In one example, the BACnet/MSTP layer544 may parse the received BACnet data to isolated data associated withone or more BACnet Objects 533. For example, the BACnet/MSTP layer 544may first parse the data based on data type (analog, binary, multistate,etc.). The BACnet/MSTP layer 544 may then evaluate an ID associated withthe BACnet data to determine what BACnet object is associated with thereceived BACnet data. The BACnet/MSTP layer 544 may then transmit theparsed BACnet data to one or more BACnet objects 533 via the networkinterface. For example, the BACnet/MSTP layer 544 may transmit parsedanalog BACnet data to the analog BACnet object 540, parsed binary BACnetdata to the binary BACnet object 538, and parsed multistate BACnet datato the multistate BACnet object 542. This is exemplary only, as theremay be more BACnet object types available as described above. Further,multiples of each BACnet object type may further be provided. In oneembodiment, the BACnet/MSTP layer 544 can instruct the network interfaceto generate new BACnet objects when BACnet data is received that is notassociated with an existing BACnet object 533. The BACnet objects 533may then provide the associated BACnet Object data to the mapping module534. The mapping module 534 may then receive the BACnet Object data byquerying each of the BACnet objects to determine if a value had beenupdated. Alternatively, the BACnet objects may provide an interrupt, orother signal, to the mapping module 534 to instruct the mapping module534 to read a new BACnet object 533 value. The mapping module 534 maythen evaluate the received BACnet object data to determine whichattribute of the equipment object 520 the received BACnet object data isassociated with and transmit the data to the equipment object 520 asequipment object attribute data via the network interface 518. In oneembodiment, the mapping module 534 transmits equipment object attributedata for each of the one or more BACnet objects 533 to the equipmentobject 520 where the equipment object attributes associated with the oneor more BACnet objects are exposed to the network interface 518.Similarly, the mapping module 534 may only transmit equipment objectattribute data to the equipment object 520 where the associatedequipment object attribute is a writeable attribute. As will bedescribed later, a user, via a configuration tool, can configureequipment object attributes that are exposed and/or writable.

The equipment object 520 may then transmit attribute values to thecommunication task module 522. The attribute values may contain theattribute ID, as well as the data type and value. Alternatively, theattribute values may only contain the value associated with theattribute. In some embodiment, the communication task module 522 readsthe attribute values for the equipment object attributes, and determinesif any values have been changed. The communication task module 522,receiving the equipment object attribute values, may then convert theattribute values into one or more actuator controller serial datapackets. The actuator controller serial data packets may be configuredsuch that the data packets are readable by the actuator 1400. Theactuator controller data packets may then be read by the UART 524 andconverted into a UART compatible serial data packet. In one example, theAPI 530, as described above, may be used to convert the host controlserial data packets into UART compatible serial data packets. In otherexamples, the UART 524 may convert the attribute values into UARTcompatible serial data packets itself. The UART 524 may then transmitthe UART compatible serial data packet containing the attribute valuesto the actuator 1400. The UART 1506 can receive the UART compatibleserial data packet and convert the data back into actuator controllerserial data packets, readable by the actuator 1500 controller. In oneembodiment, the UART 1506 can perform the conversion. In otherembodiments, the API 1510 may convert the UART compatible serial datapacket into an actuator controller serial data packet. The actuatorcontroller serial data packet may then be received by the host interface1508. The host interface 1508 may then convert the host controllerserial data packet into actuator data to be processed by the processingcircuit 1504. The actuator data may be a proprietary data format used bythe processing circuit 1504 of the actuator 1400. In other examples, theactuator data may be a standard data type used by the particularprocessing circuit 1504.

The processing circuit 1504 can then read the actuator data via the hostapplication 1512. The host application 1512 allows the data to be parsedand executed. The host application 1512 may then output deviceparameters to the actuator controller interface 1522. The actuatorcontroller interface 1522 can then communicate one or more deviceparameters to one or more actuator components. For example, the actuatorcontroller interface 1522 can provide the device parameters to the motordrive inverter 1524. In one example, the device parameter may be adesired speed and/or direction for driving a motor coupled to the motordrive inverter 1524. Thus, a command or request may be generated by thenetwork 504 and/or the controller 506 and executed at a component levelof the actuator 1400 using the above embodiment.

Turning now to FIG. 17 a block diagram illustrating the flow of datafrom the actuator controller 1502 to the network 504 and/or thecontroller 506 is shown, according to some embodiments. Within theactuator 1400, one or more of the components may provide deviceparameters associated with one or more parameters of the components ofthe actuator 1400 to the processing circuit 1504 via the actuatorcontroller interface 1522. Example components of the actuator 1400 mayinclude the motor current sensor 1518 and the one or more positionsensors 1520, as described above. However, additional components arecontemplated. The device parameters can include parameters related tomotor current, positions of the drive device 1528, or any other deviceparameters associated with the actuator 1400. The device parameters canbe provided to the host application 1512 via the actuator controllerinterface 1522. The device parameters can be processed by the hostapplication 1512 within the processing circuit 1504. In some embodimentsthe processing circuit 1504 may determine that the received deviceparameters may need to be provided to the network 504 and/or thecontroller 506. For example, the processing circuit 1504 may beconfigured to provide all updated parameters to the network 504 and/orthe controller 506. In other examples, the processing circuit 1504 maybe configured to provide device parameters to the network 504 and/or thecontroller 506 when the device parameters exceed a certain value. Instill further examples, the processing circuit 1504 may provide thedevice parameters to the network 504 and/or the controller 506 atpredetermined intervals or at predetermined times of the day. Forexample, the processing circuit 1504 may be configured to provide thedevice parameters to the network 504 and/or the controller 506 at 6A.M., Noon, 6 P.M. and Midnight. However, the predetermined intervals ortimes may be any predetermined intervals or times provided by a user.Additionally, the processing circuit 1504 may be configured to providethe device parameters to the network 504 and/or controller 506 uponreceiving an instruction to do so from the network 504 and/or thecontroller 506. This may be in conjunction with any of the otherconfigurations described above. Further, the processing circuit 1504 mayalso provide additional data associated with the processing circuit 1504itself, such as alarms, data logs, etc.

The processing circuit 1504 may provide actuator data containing datarelating to the actuator 1400 (e.g. data associated with the processingcircuit 1504 and/or the host device components 1518, 1520) to the hostinterface 1508. The host interface 1508 may be configured to receive theactuator data and convert the host device data received from theprocessing circuit 1504 into one or more actuator controller serial datapackets for transmission to the communications circuit 500. The actuatorcontroller serial data packets may then be provided to the actuatorcontroller UART 1506, which may convert the actuator controller serialdata packets into a UART compatible serial data packet. In oneembodiment, UART 1506 may convert the actuator controller serial datapacket into the UART compatible serial data packet. Alternatively, theAPI 1510 may be used to convert the actuator controller serial datapacket into the UART compatible serial data packet. The UART serial datapacket may then be transmitted to the UART 524 of the communicationscircuit 500. The UART 524 may then convert the UART serial data packetback into the actuator controller serial data packet. In one embodimentthe UART 524 converts the UART serial data packet into the actuatorcontroller serial data packet. In other embodiments, the API 530converts the UART serial data packet into the actuator controller serialdata packet.

The actuator controller serial data packet may then be received by thecommunication task module 522. The communication task module can readthe actuator controller serial data packet and parse the actuatorcontroller serial data packet to extract one or more attribute values.In one embodiment, the attribute values are values associated with theactuator 1400, such as the device parameters of the actuator components1518, 1520, or values associated with the processing circuit 1504. Thecommunication task module 522 may then output the attribute values tothe respective attributes within the equipment object 520. In oneembodiment, the communication task module 522 may determine which parsedvalues are associated with a given attribute of the equipment object 520by reading an identifier associated with each portion of the receiveddata, and map that to a corresponding attribute within the attributevalue. In one example, a user can configure the equipment objectattributes to relate to data received from the actuator 1400 byassigning certain data identifiers contained within the actuatorcontroller serial data packet to a given equipment object attribute. Aswill be discussed in more detail below, the equipment object 520 can beconfigured using a configuration device.

The attribute values stored within the attributes of the equipmentobject 520 can be read by the mapping module 534. The mapping module 534may determine if an attribute value has changed by constantly monitoringthe equipment object 520. In other embodiments, the equipment object 520may provide an interrupt signal to the mapping module 534, indicatingthat an attribute value has been updated. The mapping module 534 maythen read the equipment object attribute data from the equipment object520 and convert the equipment object attribute data in to BACnet objectdata. The mapping module 534 may further be configured to then transmitthe updated BACnet Object Data to the appropriate BACnet object 533. Insome instances, a BACnet object may not currently exist that isassociated with a particular equipment object attribute. The mappingmodule 534 may then generate a new BACnet object via the networkinterface 518. In one embodiment, the mapping module 534 may already beconfigured to associate a given BACnet object 533 with an equipmentobject 520 attribute. In one embodiment, the mapping module 534 may readan attribute ID for each received equipment object attribute data todetermine which BACnet object to map the received data to. In someembodiments, the equipment object 520 may be configured to not exposecertain attributes to the mapping module 534. In those instances, thereceived attribute values are stored in the equipment object 520, butare not provided to the mapping module 534.

Once the BACnet objects 533 receive the BACnet object data, theBACnet/MSTP layer 544 can read the BACnet objects 533 to determine ifany values have been modified. In one embodiment, the BACnet/MSTP layer544 may constantly read all of the BACnet objects 533 to determine ifany values have been changed. In other embodiment, one or more of theBACnet objects 533 may provide an interrupt signal to the BACnet/MSTPlayer 544 to indicate a value has changed. The BACnet/MSTP layer 544 maythen read one or more of the BACnet objects 533 to receive parsed BACnetobject data from the BACnet objects 533. For example, if binary BACnetobject 538 contained updated information, the BACnet/MSTP layer 544 mayrequest and receive data only from the Binary BACnet object 538. TheBACnet/MSTP layer 544 receiving the parsed BACnet object data may thenconvert the parsed BACnet object data into standard BACnet data, andtransmit the BACnet data containing the data from the BMS device 503 tothe network 504 and/or the controller 506.

Turning now to FIG. 18, a block diagram illustrating a mapping betweenattributes of equipment object 520 and standard BACnet point objects 533is shown, according to some embodiments. The attributes of equipmentobject 520 can be defined by a user (e.g., using a data definition tool,or configuration tool as described below) and mapped to various types ofinternal actuator data 1532. For example, equipment object 520 is shownto include a setpoint attribute 1814, an actuator position attribute1816, a stroke length attribute 1818, an end stop locations attribute1820, a motor current attribute 1822, and a status attribute 1824. Theprocessing circuit 1504 of the actuator 1400 can be configured tointerface with the attributes of equipment object 520 in a more concisefashion than the standard BACnet point objects 533. For example, theprocessing circuit 550 can read and write various items of internalactuator data 1532 to equipment object 520 as values of attributes 1814,1816, 1818, 1820, 1822, 1824. The equipment object 520 may expose thevalues of attributes 1814, 1816, 1818, 1820, 1822, 1824 to the networkinterface 518. The mapping module 534 may then map the exposed equipmentobject attributes 1814, 1816, 1818, 1820, 1822, 1824 to the respectiveBACnet objects 533.

As shown in FIG. 18, the standard BACnet objects are shown to include ananalog value (AV) setpoint object 1802 mapped to setpoint attribute1814, an AV actuator position object 1804 mapped to actuator positionattribute 1816, an AV stroke length object 1806 mapped to stroke lengthattribute 1818, an AV end stop locations object 1808 mapped to end stoplocations attribute 1820, an AV motor current object 1810 mapped tomotor current attribute 1822, and a device object 1812. The statusattribute 1824 is not shown mapped to a BACnet object. A user can chooseto expose all or a subset of the attributes 1814, 1816, 1818, 1820,1822, 1824 as standard BACnet point objects 533 by selectively mappingall or some of attributes 1814, 1816, 1818, 1820, 1822, 1824 to theBACnet objects 533. The BACnet/MSTP layer 544 can read the one or moreBACnet objects 533 and provide the values of the BACnet objects 533 tothe controller 506 and/or the network 504.

Example Implementation—Chiller

Referring now to FIGS. 19 and 20, an illustration of an exemplarychiller 1900 and its operation are shown, according to some embodiments.The chiller 1900 is shown to include an evaporator 1902, which providesa heat exchange between the fluid returned from the HVAC system andanother fluid, such as a refrigerant. The refrigerant in the evaporator1902 of the chiller 1900 removes heat from the chilled fluid during theevaporation process, thereby cooling the chilled fluid. The refrigerantabsorbs heat from the chilled fluid and changes from a boiling liquidand vapor state to vapor inside the evaporator 1902. The chilled fluidis then circulated back to an air handling unit via piping, asillustrated in FIG. 1, for subsequent heat exchange with the load.

As shown in FIG. 20, suction at portion 2002 causes the refrigerantvapor to flow into compressor 1904 of chiller 1900 where the compressor1904 has a rotating impeller 2004 (or another compressor mechanism suchas a screw compressor, scroll compressor, reciprocating compressor,centrifugal compressor, etc.) that increases the pressure andtemperature of the refrigerant vapor and discharges it into condenser1908. The impeller 2004 is driven by motor 1906, which may have avariable speed drive (e.g. variable frequency drive). The variable speeddrive can control the speed of the motor 1906 by varying the AC waveformprovided to the motor. The impeller 2004 may further include, or becoupled to, an actuator that controls the position of pre-rotation vanes2006 at the entrance to the impeller of compressor 1904.

Discharge at portion 2008 from compressor 1904 passes through thedischarge baffle 2010 into condenser 1908 and through a sub-cooler 2012,controllably reducing the discharge back into liquid form. The liquidthen passes through a flow control orifice 2014 and through oil cooler2016 to return to evaporator 1902 to complete the cycle.

In the embodiment shown in FIG. 19, the chiller 1900 includes acontroller 1910 coupled to an electronic display 1912 such as a touchscreen at which settings for the chiller 1900 may be adjusted by a user.The controller 1910 can further include a processing circuit configuredto adjust components of the chiller to meet, for example, pressure andtemperature setpoints for the chilled fluid or refrigerant systems. Forexample, as a building's heating load changes, chiller components suchas the pre-rotation vanes 2006 and the variable speed drive of motor1906 may be adjusted to hold the building's temperature constant. If thebuilding's heating load decreases (e.g., the building cools) and/or adesired temperature setpoint for the building increases (e.g., thebuilding occupants are calling for less cooling), the variable speeddrive can be slowed and/or the pre-rotation vanes 2006 are adjusted todecrease the flow of refrigerant though the compressor 1904.

Turning now to FIG. 21, a block diagram illustrating the communicationscircuit 500 for use with the chiller 1900 is shown, according to someembodiments. More specifically, the communications circuit 500 is usedto support a variety of data communication between a controller 1910 ofthe chiller 1900, and one or more external systems or device. Asdescribed above, the communications circuit 500 can be a wired orwireless communications link and may use any of a variety of disparatecommunications protocols (e.g., BACnet, LON, WiFi, Bluetooth, NFC,TCP/IP, etc.). In some embodiments, the communications circuit 500 is anintegrated circuit, chip, or microcontroller unit (MCU) configured tobridge communications between the chiller 1900 and other externalsystems or devices. As shown in FIG. 21, the communications circuit 500is shown as integrated with the chiller 1900. However, in someembodiments, the communications circuit 500 may be a separate devicefrom the chiller 1900.

As described above, the communications circuit 500 can be configured tosupport a variety of data communications between the controller 1910 ofthe chiller 1900 and other external systems or devices (e.g., thenetwork 504, the controller 506, one or more enterprise controlapplications 508, one or more client devices 510, one or more remotesystems and/or applications 512, and/or one or more monitoring andreporting applications 514). The communication link 546 of thecommunications circuit 500 can be a wired or wireless communicationslink and may use any of a variety of disparate communications protocolsas described above (e.g., BACnet, LON, WiFi, Bluetooth, NFC, TCP/IP,etc.). In some embodiments, the communications circuit 500 is anintegrated circuit, chip, or microcontroller unit (MCU) separate from aprocessing circuit 2104 of the chiller 1900 and configured to bridgecommunications between the controller 1910 and the one or more externalsystems or devices described above. In some embodiments, thecommunications circuit 500 is the Johnson Controls BACnet on a Chip(JBOC) product, as described above.

As described above, the communications circuit 500 includes a deviceinterface 516 and a network interface 518. In one embodiment, thenetwork interface 518 is a BACnet interface for providing a BACnetinterface for the actuator 1400. The device interface 516 is shown toinclude an equipment object 520, a communications task module 522 (e.g.,a JBOC task), and a universal asynchronous receiver/transmitter (UART)interface 524. The UART interface 524 may be configured to communicatewith a corresponding UART interface 2106 of the processing circuit 2104using a UART protocol. In other embodiments, UART interfaces 524, 2106can be replaced with serial peripheral interfaces (SPI) orinter-integrated circuit (I2C) interfaces. In one example, the levelshifter 528 may be positioned between the UART interface 524 and theUART interface 2106 to modify the signal levels transmitted between theUART interfaces 524, 2106 to ensure the signals are at a proper level tobe received by both the communications circuit 500 and the chillercontroller 1910.

The communication task module 522 can be connected to the UART interface524 via an application-program interface (API) 530 and can be configuredto populate equipment object 520 with values received from theprocessing circuit 2104 via the UART interfaces 524, 2106. Thecommunication task module 522 can also read values of the equipmentobject 520 set by the network interface 518, and can provide the valuesto processing circuit 2104. Similarly, the UART interface 2106 can beconnected to a host interface 2108 via an API 2110 and can be configuredto communicate with a host application 2112 within the processingcircuit 2104.

The processing circuit 2104 may include a processor 2114 and a memory2116. The processor 2114 may be a general purpose or specific purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable processing components. The processor 2114is configured to execute computer code or instructions stored in thememory 2116 or received from other computer readable media (e.g., CDROM,network storage, a remote server, etc.).

The memory 2116 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 2116 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 2116 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 2116 may becommunicably connected to the processor 2114 via the processing circuit2104 and may include computer code for executing (e.g., by theprocessor) one or more processes described herein. When the processor2114 executes instructions stored in the memory 2116, the processor 2114generally configures the chiller controller 1910 (and more particularlythe processing circuit 2104) to complete such activities.

In one embodiment, the memory 2116 stores the host application 2112. Thehost application 2112 can include the required application for operatingthe chiller 1900. In one embodiment, the host application 2112 cangenerate updated values for the attributes of the equipment object 520,which can be communicated to the device interface 516 via the UARTinterfaces 524, 2106, as described above. The host application 2112 caninclude software to read and store data received by the chillercontroller 1910. For example, the chiller controller 1910 may includesensors for detecting various attributes of the chiller 1900. Examplesensors can include one or more temperature sensors 2118, one or morepressure sensors 2120, one or more motor current sensors 2122, as wellas other sensors such as, voltage sensors, flow sensors, etc. The hostapplication 2112 may read the data via a chiller controller interface2124, and subsequently store the data from these sensors within thememory 2116. Further, the chiller controller 1910 may include other datasuch as setpoints, position commands, diagnostic data, etc., which thehost application 2112 can further read and store in the memory 2116. Ina further embodiment, the host application 2112 can control the chiller1900 by outputting values to the individual components of the chiller1900. For example, the host application 2112 can send a command signalto a variable speed drive 2126 via the chiller controller interface2124. In one embodiment, the command signal provides a speed command tothe variable speed drive 2126. The variable speed drive 2126 can thenoutput an AC voltage at a frequency associated with the provided speedcommand to the motor 1906. In further embodiments, the host application2112 controls the chiller 1900 by sending a command signal to a vaneactuator 2130. The command signal may provide a desired position of oneor more pre-rotation vanes 2006. The vane actuator 2130 may receive thecommand signal and drive an output device to control a position of theone or more pre-rotation vanes 2006.

The host application 2112 can further receive data and/or commands forcontrolling the chiller controller 1910. In one embodiment, the hostinterface 2108 may receive data via the UART interface 2106, andcommunicate the data to the host application 2112. For example, thechiller controller 1910 may communicate with the communications circuit500 and change a setpoint within the analog value BACnet object 540. Thenetwork interface 518 can then modify the corresponding attribute in theequipment object 520, which can then be communicated to the host devicevia the UART interfaces 524, 2106. The host interface 2108 can thenreceive the data via the host API 2110. The host interface 2108 may beconfigured to convert the received data (e.g. the setpoint change) intoa format compatible with the host application 2112. The host application2112, receiving the data (setpoint change) can then implement thesetpoint change on the chiller controller 1910. In one embodiment, thehost application 2112 can control components of the chiller 1900, suchas the motor 1906 via the variable speed driver 2126, and thepre-rotation vanes 2006 via the vane actuators 2130. In someembodiments, the host application 2112 may receive inputs or commandsdirectly from the user interface 1912 of the chiller controller 1910.The host application 2112 can then update any changes provided via theuser interface in the equipment object 520 by communicating the changesto the host interface 2108. The host interface 2108 may then communicatethe changes to the equipment object 520 via the UART interfaces 524,2106.

As described above, the equipment object 520 can be a proprietaryequipment object configured to expose internal chiller data 2132 to thenetwork interface 518. Attributes of equipment object 520 can be definedby a user (e.g., using a data definition tool) to expose any type ofinternal chiller data 2132 to the network interface 518. For example,attributes of equipment object 520 can include the sensed motor current,end stop locations, actuator status, stroke length, actuator position,setpoints, and/or any other type of variable or parameter used or storedinternally by chiller 1900.

The host application 2112 can generate updated values for the attributesof the equipment object 520, which can be communicated to the deviceinterface 516 via the UART interfaces 524, 2106. The attributes of theequipment object 520 can be read by the network interface 518 andcommunicated to the network 504 as standard BACnet objects 533. Asdescribed above, the BACnet objects 533 may include the file object 535,the device object 536, the analog value object 540, the binary valueobject 538, and the multistate value object 542. The BACnet objects 533can be mapped to corresponding attributes of the equipment object 520 bythe mapping module 534 to expose such attributes as standard BACnetobjects, as described above, and further illustrated in FIGS. 22-24,below.

Still referring to FIG. 21, the network interface 518 is shown toinclude the BACnet/MSTP layer 544. The BACnet/MSTP layer 544 can beconfigured to interface with BACnet objects 533 and the externalcommunications network 504 (e.g., a BACnet network). In someembodiments, the BACnet/MSTP layer 544 communicates directly with thecontroller 506. The BACnet/MSTP layer 544 can be configured tofacilitate BACnet communications using the MSTP Master protocol. Forexample, the BACnet/MSTP layer 544 can be configured to transmit andreceive segmented messages and automatically determine a baud rate. TheBACnet/MSTP layer 544 may support duplicate address avoidance by keepinga second device with a duplicate address from interfering with existingtraffic. In other embodiments, the BACnet/MSTP layer 544 may use othertypes of communications protocols such as TCP/IP, Ethernet, WiFi,Zigbee, NFC, etc.

The BACnet/MSTP layer 544 can be configured to read and write values tothe BACnet objects 533. For example, the BACnet/MSTP layer 544 mayreceive a position setpoint from the controller 506 and update aninstance of the analog value object 540 with the position setpoint. Thenetwork interface 518 can be configured to write the values of BACnetobjects 533 to attributes of equipment object 520, as will be shown inmore detail below. The attribute values of equipment object 520 can becommunicated to the processing circuit 2104 via the UART interfaces 524,2106 and used by the processing circuit 2104 to operate the chiller1900. Similarly, the internal chiller data 2132 generated by theprocessing circuit 2104 can be written to the equipment object 520,mapped to BACnet objects 533, and read by the BACnet/MSTP layer 544. TheBACnet/MSTP layer 544 can send the values of BACnet objects 533 to thecontroller 506, the network 504, the one or more client devices 510, theremote systems and applications 512, the enterprise control applications508, and/or the monitoring and reporting applications 514.

Referring now to FIG. 22, a block diagram illustrating the flow of datafrom the network 504 and/or the controller 506 to the chiller 1900 isshown, according to some embodiments. As shown in FIG. 22, network 504is a BACnet network; however, other networks are contemplated. Thenetwork 504 and/or the controller 506 may provide BACnet data to thecommunications circuit 500. The BACnet data may be received by theBACnet/MSTP layer 544. The BACnet/MSTP layer 544 may parse the receivedBACnet data. In one example, the BACnet/MSTP layer 544 may parse thereceived BACnet data to isolated data associated with one or more BACnetObjects 533. For example, the BACnet/MSTP layer 544 may first parse thedata based on data type (analog, binary, multistate, etc.). TheBACnet/MSTP layer 544 may then evaluate an ID associated with the BACnetdata to determine what BACnet object is associated with the receivedBACnet data. The BACnet/MSTP layer 544 may then transmit the parsedBACnet data to one or more BACnet objects 533 via the network interface.For example, the BACnet/MSTP layer 544 may transmit parsed analog BACnetdata to the analog BACnet object 540, parsed binary BACnet data to thebinary BACnet object 538, and parsed multistate BACnet data to themultistate BACnet object 542. This is exemplary only, as there may bemore BACnet object types available as described above. Further,multiples of each BACnet object type may further be provided. In oneembodiment, the BACnet/MSTP layer 544 can instruct the network interfaceto generate new BACnet objects when BACnet data is received that is notassociated with an existing BACnet object 533. The BACnet objects 533may then provide the associated BACnet Object data to the mapping module534. The mapping module 534 may then receive the BACnet Object data byquerying each of the BACnet objects to determine if a value had beenupdated. Alternatively, the BACnet objects may provide an interrupt, orother signal, to the mapping module 534 to instruct the mapping module534 to read a new BACnet object 533 value. The mapping module 534 maythen evaluate the received BACnet object data to determine whichattribute of the equipment object 520 the received BACnet object data isassociated with and transmit the data to the equipment object 520 asequipment object attribute data via the network interface 518. In oneembodiment, the mapping module 534 transmits equipment object attributedata for each of the one or more BACnet objects 533 to the equipmentobject 520 where the equipment object attributes associated with the oneor more BACnet objects are exposed to the network interface 518.Similarly, the mapping module 534 may only transmit equipment objectattribute data to the equipment object 520 where the associatedequipment object attribute is a writeable attribute. As will bedescribed later, a user, via a configuration tool, can configureequipment object attributes that are exposed and/or writable.

The equipment object 520 may then transmit attribute values to thecommunication task module 522. The attribute values may contain theattribute ID, as well as the data type and value. Alternatively, theattribute values may only contain the value associated with theattribute. In some embodiment, the communication task module 522 readsthe attribute values for the equipment object attributes, and determinesif any values have been changed. The communication task module 522,receiving the equipment object attribute values, may then convert theattribute values into one or more chiller controller serial datapackets. The chiller controller serial data packets may be configuredsuch that the data packets are readable by the chiller 1900. Theactuator controller data packets may then be read by the UART 524 andconverted into a communication circuit UART compatible serial datapacket. In one example, the API 530, as described above, may be used toconvert the host control serial data packets into communication circuitUART compatible serial data packets. In other examples, the UART 524 mayconvert the attribute values into UART compatible serial data packetsitself. The UART 524 may then transmit the communication circuit UARTcompatible serial data packet containing the attribute values to thechiller UART 2106 via the level shifter 528. The level shifter 528 canconvert the communications circuit UART compatible serial data packetinto a chiller UART compatible serial data packet, which can be receivedby the chiller UART 2106. In some examples, the communications circuitUART can transmit the communications circuit UART compatible serial datapacket directly to the chiller UART 2106 where the communication circuitUART 524 and the chiller UART 2106 use the same serial data packetsignal levels. The chiller UART 2106 can receive the chiller UARTcompatible serial data packet and convert the data back into chillercontroller serial data packets, readable by the chiller controller 1910.In one embodiment, the UART 2106 can perform the conversion. In otherembodiments, the API 2110 may convert the UART compatible serial datapacket into an actuator controller serial data packet. The actuatorcontroller serial data packet may then be received by the host interface2108. The host interface 2108 may then convert the chiller controllerserial data packet into chiller data to be processed by the processingcircuit 2104. The chiller data may be a proprietary data format used bythe processing circuit 2104 of the chiller 1900. In other examples, thechiller data may be a standard data type used by the particularprocessing circuit 2104.

The processing circuit 2104 can then read the chiller data via the hostapplication 2112. The host application 2112 allows the data to be parsedand executed. The host application 2112 may then output deviceparameters to the chiller controller interface 2124. The chillercontroller interface 2124 can then communicate one or more deviceparameters to one or more chiller components. For example, the chillercontroller interface 2124 can provide the device parameters to thevariable speed drive 2126 and/or the vane actuator 2130. In one example,the device parameter may be a desired speed and/or direction for drivingthe motor 1906 coupled to the variable speed drive 2126. In anotherexample, the device parameter may be a desired position of apre-rotation vane 2006 coupled to the vane actuator 2130. Thus, acommand or request may be generated by the network 504 and/or thecontroller 506 and executed at a component level of the chiller 1900using the above embodiment.

Turning now to FIG. 23, a block diagram illustrating the flow of datafrom the chiller controller 1910 to the network 504 and/or thecontroller 506 is shown, according to some embodiments. Within thechiller 1900, one or more of the components may provide deviceparameters associated with one or more parameters of the components ofthe chiller 1900. The device parameters may be provided to theprocessing circuit 2104 via the chiller controller interface 2124.Example components of the chiller 1900 may include the motor currentsensor 2122, the pressure sensor 2120, and the temp sensors 2118, asdescribed above. However, additional components are contemplated. Thedevice parameters can include parameters related to motor current,pressure within the chiller, water temperature, or any other deviceparameters associated with the chiller 1900. The device parameters canbe provided to the host application 2112 via the chiller controllerinterface 2124. The device parameters can be processed by the hostapplication 2112 within the processing circuit 2104. In some embodimentsthe processing circuit 2104 may determine that the received deviceparameters may need to be provided to the network 504 and/or thecontroller 506. For example, the processing circuit 2104 may beconfigured to provide all updated parameters to the network 504 and/orthe controller 506. In other examples, the processing circuit 2104 maybe configured to provide device parameters to the network 504 and/or thecontroller 506 when the device parameters exceed a certain value. Instill further examples, the processing circuit 2104 may provide thedevice parameters to the network 504 and/or the controller 506 atpredetermined intervals or at predetermined times of the day. Forexample, the processing circuit 2104 may be configured to provide thedevice parameters to the network 504 and/or the controller 506 at 6A.M., Noon, 6 P.M. and Midnight. However, the predetermined intervals ortimes may be any predetermined intervals or times provided by a user.Additionally, the processing circuit 2104 may be configured to providethe device parameters to the network 504 and/or controller 506 uponreceiving an instruction to do so from the network 504 and/or thecontroller 506. This may be in conjunction with any of the otherconfigurations described above. Further, the processing circuit 2104 mayalso provide additional data associated with the processing circuit 2104itself, such as alarms, data logs, etc.

The processing circuit 2104 may provide chiller data containing datarelating to the chiller 1900 (e.g. data associated with the processingcircuit 2104 and/or the chiller components 2118, 2120, 2122) to the hostinterface 2108. The host interface 2108 may be configured to receive theactuator data and convert the host device data received from theprocessing circuit 2104 into one or more chiller controller serial datapackets for transmission to the communications circuit 500. The chillercontroller serial data packets may then be provided to the chillercontroller UART 2106, which may convert the chiller controller serialdata packets into a chiller UART compatible serial data packet. In oneembodiment, UART 2106 may convert the chiller controller serial datapacket into the chiller UART compatible serial data packet.Alternatively, the API 2110 may be used to convert the chillercontroller serial data packet into the chiller UART compatible serialdata packet. The chiller UART compatible serial data packet may then betransmitted to the UART 524 of the communications circuit 500. In oneembodiment, the level shifter 528 converts the chiller UART compatibleserial data packet into a communications circuit UART compatible serialdata packet. In other embodiments, the chiller UART 2106 can transmitthe chiller UART compatible serial data packet directly to thecommunications circuit UART 524 where the communication circuit UART 524and the chiller UART 2106 use the same serial data packet signal levels.The communication circuit UART 524 may then convert the communicationcircuit UART compatible serial data packet back into the chillercontroller serial data packet. In one embodiment the communicationscircuit UART 524 converts the communication circuit UART compatibleserial data packet into the chiller controller serial data packet. Inother embodiments, the API 530 converts the communications circuit UARTcompatible serial data packet into the chiller controller serial datapacket.

The chiller controller serial data packet may then be received by thecommunication task module 522. The communication task module 522 canread the chiller controller serial data packet and parse the chillercontroller serial data packet to extract one or more attribute values.In one embodiment, the attribute values are values associated with thechiller 1900, such as the device parameters of the chiller components2118, 2120, 2122, or values associated with the processing circuit 2104.The communication task module 522 may then output the attribute valuesto the respective attributes within the equipment object 520. In oneembodiment, the communication task module 522 may determine which parsedvalues are associated with a given attribute of the equipment object 520by reading an identifier associated with each portion of the receiveddata, and map that to a corresponding attribute within the attributevalue. In one example, a user can configure the equipment objectattributes to relate to data received from the chiller 1900 by assigningcertain data identifiers contained within the actuator controller serialdata packet to a given equipment object attribute. As will be discussedin more detail below, the equipment object 520 can be configured using aconfiguration device and/or tool.

The attribute values stored within the attributes of the equipmentobject 520 can be read by the mapping module 534. The mapping module 534may determine if an attribute value has changed by constantly monitoringthe equipment object 520. In other embodiments, the equipment object 520may provide an interrupt signal to the mapping module 534, indicatingthat an attribute value has been updated. The mapping module 534 maythen read the equipment object attribute data from the equipment object520 and convert the equipment object attribute data in to BACnet objectdata. The mapping module 534 may further be configured to then transmitthe updated BACnet Object Data to the appropriate BACnet object 533. Insome instances, an BACnet object may not current exist that isassociated with a particular equipment object attribute. The mappingmodule 534 may then generate a new BACnet object via the networkinterface 518. In one embodiment, the mapping module 534 may already beconfigured to associate a given BACnet object 533 with an equipmentobject 520 attribute. In one embodiment, the mapping module 534 may readan attribute ID for each received equipment object attribute data todetermine which BACnet object to map the received data to. In someembodiments, the equipment object 520 may be configured to not exposecertain attributes to the mapping module 534. In those instances, thereceived attribute values are stored in the equipment object 520, butare not provided to the mapping module 534.

Once the BACnet objects 533 receive the BACnet object data, theBACnet/MSTP layer 544 can read the BACnet objects 533 to determine ifany values have been modified. In one embodiment, the BACnet/MSTP layer544 may constantly read all of the BACnet objects 533 to determine ifany values have been changed. In other embodiment, one or more of theBACnet objects 533 may provide an interrupt signal to the BACnet/MSTPlayer 544 to indicate a value has changed. The BACnet/MSTP layer 544 maythen read one or more of the BACnet objects 533 to receive parsed BACnetobject data from the BACnet objects 533. For example, if binary BACnetobject 538 contained updated information, the BACnet/MSTP layer 544 mayrequest and receive data only from the Binary BACnet object 538. TheBACnet/MSTP layer 544 receiving the parsed BACnet object data may thenconvert the parsed BACnet object data into standard BACnet data, andtransmit the BACnet data containing the data from the BMS device 503 tothe network 504 and/or the controller 506.

Turning now to FIG. 24, a block diagram illustrating a mapping betweenattributes of equipment object 520 and one or more BACnet objects 533 isshown, according to some embodiments. The attributes of equipment object520 can be defined by a user (e.g., using a data definition tool, orconfiguration tool as described below) and mapped to various types ofinternal chiller data 2132. For example, equipment object 520 is shownto include a setpoint attribute 2402, an outlet temperature attribute2404, an outlet pressure attribute 2406, a motor speed attribute 2408, amotor current attribute 2410, and a status attribute 2412. Theprocessing circuit 2104 of the chiller 1900 can be configured tointerface with the attributes of equipment object 520 in a more concisefashion than the standard BACnet point objects 533. For example, theprocessing circuit 550 can read and write various items of internalchiller data 2132 to equipment object 520 as values of attributes 2402,2404, 2406, 2408, 2410, 2412. The equipment object 520 may expose thevalues of attributes 2402, 2404, 2406, 2408, 2410, 2412 to the networkinterface 518. The mapping module 534 may then map the exposed equipmentobject attributes 2402, 2404, 2406, 2408, 2410, 2412 to the respectiveBACnet objects 533.

As shown in FIG. 24, the standard BACnet objects are shown to include ananalog value (AV) setpoint object 2414 mapped to setpoint attribute2402, an AV outlet temperature object 2416 mapped to outlet temperatureattribute 2404, an AV outlet pressure object 2418 mapped to outletpressure attribute 2406, an AV motor speed object 2420 mapped to motorspeed attribute 2408, an AV motor current object 2422 mapped to motorcurrent attribute 2410, and a device object 2424. The status attribute2412 is not shown mapped to a BACnet object. A user can choose to exposeall or a subset of the attributes 2402, 2404, 2406, 2408, 2410, 2412 asstandard BACnet point objects 533 by selectively mapping all or some ofattributes 2402, 2404, 2406, 2408, 2410, 2412 to BACnet objects 533. TheBACnet/MSTP layer 544 can read the one or more BACnet objects 533 andprovide the values of the BACnet objects 533 to the controller 506and/or the network 504.

Communication Circuit Programming Tools

In some applications, tools may be used to program the communicationcircuit. For example, a tool may be used to program an equipment objectof a communication circuit, such as that described in FIGS. 5 and 7. InFIG. 25, a block diagram of a programming system 2500 used to program acommunication circuit 2502 within a BMS device 2504 is shown, accordingto some embodiments. In one embodiment, the BMS device 2504 is an HVACdevice, such as a chiller, an actuator, a valve, an AHU, an RTU, aboiler, etc. In one example, the communication circuit 2502 isintegrated into the BMS device 2504. In some embodiments, thecommunication circuit 2502 is integrated with a device controller 2506of the BMS device 2504. In further embodiments, the communicationcircuit 2502 is a separate device from the BMS device 2504, andconfigured to couple to the BMS device 2504. The communications circuit2502 is shown in a simplified form from communications circuit 500,described above. Therefore, it is contemplated that communicationcircuit 2502 includes the same components, and has the samefunctionality as communications circuit 500 described above.

The communication circuit 2502 is shown to include a network interface2508 and a device interface 2510. The network interface 2508 is shown toinclude a mapping module 2512, one or more BACnet objects 2514, and aBACnet/MSTP layer 2516. The mapping module 2512, the BACnet objects 2514and the BACnet/MSTP layer 2516 may have similar functionality to themapping module 534, the BACnet objects 533 and the BACnet/MSTP layer 544described above. The device interface 2510 may include an equipmentobject 2518, a communication task module 2520 and a UART interface 2522.Again, the equipment object 2518, the communication task 2520 and theUART interface 2522 may have similar functionality to the equipmentobject 520, the communication task module 522, and the UART interface524 described above.

The BMS device controller 2506 may include a processing circuit 2524,the processing circuit 2524 may include a processor 2526 and a memory2528. The processor 2526 may be a general purpose or specific purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable processing components. The processor 2526is configured to execute computer code or instructions stored in thememory 2528 or received from other computer readable media (e.g., CDROM,network storage, a remote server, etc.).

The memory 2528 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 2528 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 2528 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 2528 may becommunicably connected to the processor 2528 via the processing circuit2524 and may include computer code for executing (e.g., by theprocessor) one or more processes described herein. When the processor2526 executes instructions stored in the memory 2528, the processor 2526generally configures the BMS device controller 2506 (and moreparticularly the processing circuit 2524) to complete such activities.In one embodiment, the memory 2526 stores a host application 2530. Thehost application 2530 can include the required application for operatingthe BMS device 2504.

The BMS device controller 2506 is further shown to include a hostinterface 2532 and a UART interface 2534. The host interface 2532 mayhave similar functionality to host interface 532 described above inFIGS. 5A-5C. Specifically, the host interface 2532 may providecommunication between the processing circuit 2524 and the UART interface2534. The UART interface 2534 is configured to interface with the UARTinterface 2522 on the communications circuit 2502.

The system 2500 is shown to include a configuration device 2536. It iscontemplated that the configuration device 2536 can be used to programthe communication circuit 2502 regardless of the relationship of thecommunication circuit 2502 to the BMS device 2504. The configurationdevice 2536 is configured to setup and configure the equipment object2518 of the communication circuit 2502 for communication with the BMSdevice 2504 automatically. For example, and as described in more detailbelow, the configuration device 2536 can allow a user to configure thecommunication circuit 2502 to work with the BMS device 2504, without anyspecialized knowledge of how to interface with the external network(e.g. BACnet). The configuration device may be a general purposecomputer (PC), a laptop, a mobile device, such as a tablet computer(iPad, Android Tablet, Microsoft Surface), or a smartphone (iPhone,Android phone, Windows Phone, etc.). In some embodiments, theconfiguration device 2536 is a dedicated device.

As shown in FIG. 25, the configuration device 2536 is shown to include aprocessing circuit 2538. The processing circuit 2538 includes aprocessor 2540 and a memory 2542. In one embodiment, the processor 2540and the memory 2542 may be the same as the MCU 702 and the memory 704described in FIG. 7, above. The processor 2540 may be a general purposeor specific purpose processor, an application specific integratedcircuit (ASIC), one or more field programmable gate arrays (FPGAs), agroup of processing components, or other suitable processing components.The processor 2540 is configured to execute computer code orinstructions stored in the memory 2542 or received from other computerreadable media (e.g., CDROM, network storage, a remote server, etc.).

The memory 2542 may include one or more devices (e.g., memory units,memory devices, storage devices, etc.) for storing data and/or computercode for completing and/or facilitating the various processes describedin the present disclosure. The memory 2542 may include random accessmemory (RAM), read-only memory (ROM), hard drive storage, temporarystorage, non-volatile memory, flash memory, optical memory, or any othersuitable memory for storing software objects and/or computerinstructions. The memory 2542 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present disclosure. The memory 2542 may becommunicably connected to the processor 2540 via the processing circuit2538 and may include computer code for executing (e.g., by theprocessor) one or more processes described herein. When the processor2540 executes instructions stored in the memory 2542, the processor 2540generally configures the configuration device 2536 to complete suchactivities. The communication tool 2536 may further include a userinterface 2544 and a communication interface 2546. The user interface2544 may be a keyboard, a touchscreen, a display and keypad combination,a microphone, a mouse, or any other interface device allowing a user tointerface with the configuration tool 2536. The communication interface2546 may be a serial data port, such as RS-232, RS-485, etc. In otherembodiments, the communication interface 2546 may be an external device,such as a Cheetah SPI flash programming tool. In one embodiment, thecommunication interface 2546 is configured to interface with aperipheral port 2548 of the communications circuit 2502. The peripheralport 2548 may couple to an SPI driver 2550 to allow a user to interfacewith the network interface 2508, the device interface 2510, or a memory2552 of the communications circuit 2502. In one embodiment, the memory2552 is a serial flash type memory.

In one embodiment, the configuration device 2536 is a tool used todefine configuration data which may be stored on the memory 2552 of thecommunication circuit 2502. In one embodiment, the processing circuit2538 can be configured to execute a configuration wizard 2554 stored inthe memory 2542. In one embodiment, the configuration wizard 2554 is aJBOC configuration wizard from Johnson Controls. The configurationwizard 2554 may present a user, via the user interface 2544, withmultiple sections to be completed by a user to configure thecommunication circuit 2502. For example, the configuration wizard 2554may require a list of all of the data the BMS device 2504 wishes toexpose to an external network, such as a BACnet network. In oneembodiment, this data is primary information required for configurationof the communication circuit 2502.

The configuration wizard 2554 may further require a user to selectsetting that configure how the communication circuit 2502 will interactwith the BMS device 2504. Example settings can include baud rate,timing, data types associated with various attributes; etc. Theconfiguration wizard 2554 may further require a user to provide datathat describes views of the data that can be utilized by other userinterface devices, such as a commissioning tool. Additionally, the viewsmay further be provided for future BACnet Structure view objects thatmay organize the data.

Once the configuration wizard 2554 has received the required input fromthe user, the configuration wizard 2554 can generate an image file 2556that includes a desired configuration for the communication circuit2502. For example, the image file 2556 may include equipment objectattributes associated with BMS device 2504, mapping of the equipmentobject attributes to associated BACnet objects, required BACnet objects,equipment attribute data types, equipment attribute names and/oridentification information, read/write permissions for the equipmentobject attributes, exposure permissions of the equipment objectattributes, etc. The image file 2556 may further include configurationdata relating to alarming, scheduling, communications (UART, WiFi,TCP/IP, etc.), trending, and scheduling, as it relates to the BMS device2504. The image file 2556 may be transmitted to the communicationcircuit 2502 via the communication interface 2546. The communicationscircuit 2502, receiving the image file via the peripheral port 2548, maystore the image file in the memory 2552. The image file 2556 may then beaccessed by a processor 2558 of the communications circuit. Theprocessor 2558 may be configured to interface with the device interface2510 and the network interface 2508, and can read/write data to themodules contained therein. For example, the processor 2558 may writeattribute data stored within the image file 2556 to the equipment object2518. The processor 2558 may be a general purpose or specific purposeprocessor, an application specific integrated circuit (ASIC), one ormore field programmable gate arrays (FPGAs), a group of processingcomponents, or other suitable processing components. The processor 2558is configured to execute computer code or instructions stored in thememory 2552 or received from other computer readable media (e.g., CDROM,network storage, a remote server, etc.).

Turning now to FIG. 26 a process 2600 for configuring a communicationcircuit is shown, according to some embodiments. At process block 2602,a user can define equipment object attributes of a communicationcircuit. In one embodiment, the user defines the equipment objectattributes using a configuration wizard, such as configuration wizard2554 described above. Defining the equipment object attributes mayinclude equating the attributes with one or more data points associatedwith a BMS device coupled to the communication circuit. The BMS devicemay be any BMS device, as described above. Defining the equipment objectattributes may further include defining parameters associated with thedata from the BMS device, including data type, data names, value ranges,data format, etc. Defining the equipment object attributes may furtherinclude defining which equipment object attributes are to be exposed toan external network, such as a BACnet network, by the communicationscircuit. Additionally, defining the equipment object attributes mayfurther include defining which attributes are writable.

At process block 2604, associations of the equipment object attributesto one or more BACnet objects can be defined. In one embodiment,defining the associations can include defining what type of BACnetobjects are needed to be associated with the equipment attributes. Forexample, the BACnet objects may need to be first defined as analog dataobjects, binary data objects, multistate data objects, file objects,device objects, etc. In one embodiment, the associations are defined inthe configuration wizard 2554. In some embodiment, the configurationwizard may automatically define the associations between equipmentobject attributes and BACnet objects, including defining the BACnetobjects generally. In other examples, a user may define the associationsmanually, using the configuration device 2536. At process block 2606,the configuration wizard 2554 generates an image file including thedefined equipment object attributes and defined associations of theequipment object attributes to the BACnet objects. The image file mayalso include general configuration parameters associated withconfiguring the communications circuit, as described above.

At process block 2608, the image file is uploaded to a memory of thecommunications circuit, such as the memory 2552 described above. Atprocess block 2610, the equipment object attributes are configured basedon the definitions stored within the image file. In one embodiment, aprocessor of the communications circuit may configure the equipmentobjects based on the image file. In other embodiments, a deviceinterface of the communications circuit may configure the equipmentobjects based on the image file. At process block 2612, BACnet objectsare generated based on the received image file. In one embodiment, aprocessor of the communications circuit may generate the BACnet objectsbased on the received image file. Alternatively, a network interface ofthe communications circuit may generate the BACnet objects based on thereceived image file. In still further examples, a mapping module, orother module of the communications circuit may generate the BACnetobjects based on the received image file. In process block 2614, amapping module of the communications circuit is configured based on thereceived image file. For example, the mapping module may be configuredto map the defined equipment object attributes to the associated BACnetobjects. The mapping module may further be configured to map definedBACnet objects to the associated equipment object attributes, where theequipment object attributes are writable. Further, the mapping modulemay further be configured to monitor and update the equipment objectattributes and/or the BACnet objects, as described in FIGS. 5A-5C,above.

Turning now to FIG. 27, an example user interface 2700 for configuringthe communications circuit 2502 using the configuration wizard 2554 isshown, according to some embodiments. In one embodiment, the user canselect an attribute ID for the desired equipment object attribute to beexposed to an external network using input box 2702. The attribute IDmay be a property ID of the value in the equipment object attribute. Inone embodiment, the equipment object attribute ID must be a valuebetween 7000-8999. The attribute ID may also be the ID used to interfacewith the BMS device controller 2506. The user can then select a datatype in the data type dropdown menu 2704. Example data types can includeBoolean, float, Enum (i.e. true or false), or long. However, other datatypes are contemplated. The user can then select whether the equipmentobject attribute will be writeable using the modify checkbox 2706. Inone example, the equipment object attribute may be writeable via aBACnet write property service. The user may then enter an object longname into input box 2708. In one embodiment, the object long name is adescription property of a data object mapped to the equipment objectattribute. The user may further enter an object short name into inputbox 2710. In one embodiment, the object short name is a string thatrepresents the Object Name property of a data object mapped to theequipment object attribute. In some embodiments, the object short nameis also the label that will be given to the corresponding equipmentobject.

The user interface 2700 may further allow a user to optionally input aclass associated with a BACoid into input box 2712. The class may be aproprietary data class associated with a particular data object type.The user may further set a unique value for the BACoid class, whichidentifies the particular BACoid object using input box 2714. Once theuser has input the BACoid class and value, a standard data object may becreated automatically to also store the data on the communicationscircuit 2502. In one embodiment, the standard data objects are standardBACnet data objects. The user may then input a default value in thedefault value input box 2714. In one embodiment, the default value isautomatically set to zero.

FIGS. 28 and 29 illustrate further user interface screens for use whereother data types are selected. For example, in FIG. 28 the data type wasset to Float by a user. A “float or long” input dialog box 2802 isgenerated by the configuration wizard 2554 to allow a user to define theFloat data object in more detail. For example, the user can selectminimum and maximum values that can be written to the equipment objectattribute, unit types, and a precision value (e.g. number of decimalplaces allowed) using the input dialog box 2802. In FIG. 29, the datatype was set to Enum by the user. An Enum dialog box 2902 can beprovided to allow a user to add, change or delete desired statesassociated with the attribute. Further, other user interfaces arecontemplated to account for other required data needed to program thecommunications circuit 2502.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements may bereversed or otherwise varied and the nature or number of discreteelements or positions may be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepsmay be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions may be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure may be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a machine, the machine properly views theconnection as a machine-readable medium. Thus, any such connection isproperly termed a machine-readable medium. Combinations of the above arealso included within the scope of machine-readable media.Machine-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing machines to perform a certain function orgroup of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps maybe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

What is claimed is:
 1. A communication circuit for use with an actuatorcomprising a processing circuit, the communication circuit comprising: adevice interface configured to provide a serial communication linkbetween the communication circuit and the processing circuit; a networkinterface in communication with the device interface and configured tocommunicate with an external network; wherein the device interface isconfigured to receive data values from the processing circuit via theserial communication link, the device interface being configured by theprocessing circuit to populate one or more attributes of an equipmentobject stored in the device interface with the data values; and whereinthe network interface is configured to map the attributes of theequipment object to individual networking objects, and write theattributes of the equipment object to the mapped individual networkingobjects, the network interface being configured to communicate theindividual networking objects to the external network
 2. Thecommunication circuit of claim 1, wherein the external network is aBACnet network.
 3. The communication circuit of claim 1, wherein thedevice interface comprises a network layer, the network layer configuredto read values contained in the individual networking objects, andtransmit the values contained in the individual networking objects tothe external network.
 4. The communication circuit of claim 1, whereinthe network interface comprises a communication link for providingcommunication between the network interface and the network.
 5. Thecommunication circuit of claim 4, wherein the communication link isconfigured to automatically determine a baud rate for communicating withthe network.
 6. The communication circuit of claim 1, wherein networkinterface selectively maps a set of the attributes of the equipmentobject to the individual networking objects, based on an instructionfrom the processing circuit.
 7. The communication circuit of claim 6,wherein the instruction is to not map attributes of the equipment objectthat are associated with a static data point of the actuator.
 8. Thecommunication circuit of claim 1, wherein the network interface isfurther configured to write external data values to one or moreattributes of the equipment object. The external data values receivedfrom the external network.
 9. The communication circuit of claim 8,wherein the device interface is further configured to transmit theexternal data values written to the one or more attributes of theequipment object to the processing circuit of the actuator via theserial communication link.
 10. A communication circuit for providingnetwork communications to an actuator, the communication circuitcomprising: a processing circuit, the processing circuit comprising: aprocessor, the processor configured to communicate with the actuatordevice, and configured to receive one or more data values from theactuator; a memory, the memory in communication with the processor andincluding an equipment object, the equipment object comprising one ormore attributes associated with the actuator; wherein the processingcircuit is configured to map the one or more received data values to theone or more attributes of the equipment object; and a networktransceiver, the network transceiver configured to transmit the mappedvalues in the equipment object to a network using a communicationinterface.
 11. The communication circuit of claim 10, wherein thecommunication interface is an RS-485 interface.
 12. The communicationcircuit of claim 10, wherein the processing circuit is furtherconfigured to map the attributes of the equipment object to individualnetworking objects for transmission to the network using the networktransceiver.
 13. The communication circuit of claim 12, wherein standardnetworking objects include at least one of file objects, device objects,analog values, binary values and multistate values.
 14. Thecommunication circuit of claim 12, wherein processing circuit is furtherconfigured to receive data values from the network, and write thereceived data to one or more of the individual networking objects. 15.The communication circuit of claim 14, wherein the processing circuit isfurther configured to map the received data written in the one or moreindividual networking objects to corresponding attributes in theequipment object.
 16. A method of communicating HVAC device attributesto a network, the method comprising: receiving one or more data valuesassociated with the HVAC device at a communication circuit via acommunication link; writing the one or more data values to an equipmentobject, the equipment object mapping the data values to an associatedattribute of the equipment object; mapping the attributes of theequipment object to one or more standard networking objects; andtransmitting the standard networking object to a network.
 17. The methodof claim 16, wherein the network is a BACnet network.
 18. The method ofclaim 16, wherein the standard network objects include at least one offile objects, device objects, analog values, binary values andmultistate values.
 19. The method of claim 16, wherein the communicationlink is a universal asynchronous receiver/transmitter (UART) interface.20. The method of claim 16, further comprising: receiving a request fromthe host device to provide data values associated with the equipmentobject; and transmitting the requested values to the host device via thecommunication link.